Modern Software Development Lifecycle – Part 2 Continuous Integration

This post is part 2 in a three-part series of posts on Software Development Lifecycle in the “Modern” development paradigm. As I explained in the previous post, I have been thinking about how to integrate client-side code into enterprise development processes. Many years ago, I was introduced to a concept called continuous integration. I even implemented it at a previous employer, it was awesome. Continuous integration is the concept that as changes are made to code they can immediately be combined and tested to make sure everything works. Then once everything checks out continuous integration tools can also handle the deployments for us. As my development has shifted from compiled code to more client-side code, I have been trying to figure out how to use the tools and processes that I have been using with client-side methodologies. I recently figured out how integrate continuous integration into my processes now. This revelation was thanks in part to the push of the SharePoint Framework. I also recently came across the fact the Visual Studio Team Services has added continuous integration capability. TFS supposedly has this feature as well. In order for this to work with our processes in SharePoint and JavaScript you will need to have a working gulp script from the previous part for these instructions to work.

Continue reading “Modern Software Development Lifecycle – Part 2 Continuous Integration”

Modern Software Development Life Cycle Part 1

I have been doing JavaScript development for many years now but it was always included as part of some other server side code that was easy to manage. When I started working on Office365 and doing 100% client side code I have struggled with the best way to manage the artifacts that are being created. With server-side code we just used Visual Studio and that would handle our connection to version control and a plethora of other tools to help us write better code. When things changed to working in Office365 I started out by adding the artifacts to a library in SharePoint and then editing them with SharePoint Designer. I know, I know, SharePoint Designer is not a good code editor but in regards to save performance, SharePoint Designer behaves better than anything else out there. The problem with this is that the code that I am creating is not stored in a centralized source repository. Also, if I wanted to get the code into the repository it was a manual effort to copy the files back to my machine and then check everything in. Dealing with multiple developers working on a project could be rather tricky since we were working on the exact same files. There have been times were changes have been temporarily lost due to a save that did not include the changes from other developers. Because of this I always make sure the library I am using has versioning turned on and sometimes I’ll require checkout depending on the likelihood of multiple devs working on the same files. Another problem with this approach is that there is no way to run any code improvement processes. If I want to use TypeScript for example, your code has to be on a local drive for the TypeScript compiler to do its thing. If you try to run it on a mapped drive through WebDav, TypeScript complains. There are also code tests, bundling, and minification that are tricky to run directly from a SharePoint library. With the introduction of the SharePoint Framework I have realized that I needed to figure out how to best handle the client-side pieces in regards to the Software Development Life cycle. This series of blog posts will cover those topics.

Continue reading “Modern Software Development Life Cycle Part 1”