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.

  1. Part 1 – New Tools and Setup – This post
  2. Part 2 – Continuous Integration
  3. Part 3 – Integrating with the SharePoint Framework

New Tools Required

With the “modern” development methods, yes this will be obsolete before too long, a new way of looking at the code was required. What I have found is my experience with what works for me. I am open to suggestions that you may have found helpful that I could integrate as this is a work in progress. In this blog post I will not be going over the SharePoint Framework in any depth. The approach we are talking about today uses some of the similar tools and concepts and I will have a follow-on article on how to integrate both client-side code and the SharePoint Framework into some cool areas for our SDLC including continuous integration and automated deployments. For today though we are going to talk about how we can simplify our processes. We will be using Visual Studio Code as our editor but this is not required. You can use whatever editor you so choose. For the nice integrations that are included is why I chose this editor. We are going to be using Visual Studio Team Services as our version control repository and we will be using gulp as our task processor. Another big factor in determining our toolset is that we need something that is not dependent on a particular operating system. So, the examples that we will be showing will work on a Windows machine, OSX, and Linux.

Visual Studio Code

There are several reasons why we are using Visual Studio Code for our process but the big ones boil down to the following:

  1. It is Free
  2. Not OS Specific
  3. Nice integration with Git

Sure, other tools can offer this as well, but these are the big reasons I have landed with this tool. Visual Studio Code is nice because, as part of the interface, we have easy integration with our version control system and some other nice auto complete features.

Visual Studio Team Services

We are using Visual Studio Team Services because it adds a lot of cool features and is super cheap to be able to use. One nice part that we will be taking advantage of is the fact that when setting up a project we can designate that VSTS will use Git as the backend for the repository. Why do we care? Because Git allows us to meet one of the goals in that we can easily integrate access from any OS plus connecting with Git for automation is a lot easier than using the standard TFS setup. As mentioned we will talk in another post on how we can use the continuous integration and deployment features of VSTS, this is some cool stuff.

Gulp

Gulp is a JavaScript based build system. Now there are several other JavaScript based systems that we could use as well. I have found Gulp to be fairly easy to use and work with while also being the chosen system for working with the SharePoint Framework. So, using Gulp means we are using the same software so we can reuse the same skills. Gulp allows us to automate builds as mentioned but in our case, we will be using it manage the deployment of our code.

Let’s Build Something

Now that we have the basics covered let’s get to the fun stuff. What we are going to be doing is we will have a pretty basic application that will show what we can do. For this we need to make sure that you have the following prerequisites installed on your machine.

  1. NodeJS – The LTS(Long Term Support) version is most likely what you need and you can install it with the defaults
  2. We will run the following command from a Node.js command prompt, start one after NodeJs finishes installing
    1. Setup your project folder
    2. Once there, run
      1. npm init – Fill out the prompts. This will setup your project file package.json
      2. npm i gulp gulp-util Fabian-Schmidt/gulp-sharepoint-sync --save-dev

        – This will add gulp and other needed code to our project.

      3. Now open your editor
    3. In the root of your project folder create a file called gulpfile.js
    4. If you are using Git as your repository create a file called “.gitignore” This fill will tell Git to ignore certain items like the node_modules folder
      1. Add the following text to the file “node_modules” without the quotes

With the basics out of the way let’s start adding some code. For this I am going to create a src folder. For our purposes, it doesn’t really matter what type of content we are going to put in it so I am going to add a few html files, a sub folder for images, and a sub folder scripts. The folder structure looks like this,

With our files in place we need to create our gulp file to handle pushing everything to SharePoint. Create a new file called gulpfile.js. To handle syncing our files to SharePoint we will be using some code contributed to the community from a git hub repo. This one handles what I want it to do and does it pretty well. The repo is at https://github.com/Fabian-Schmidt/gulp-sharepoint-sync. There are instructions there as well on how to use this. So we don’t have to store a username and a password inside of our code in version control I will be using the ACS, Access Control Services, to handle the access. I have added a config.json file to hold the client and secret so I don’t have to hard code those in files I’ll be showing you. The instructions on the git hub repo explain how to get a client id and secret. Also I have an article, Manually Registering a SharePoint Add-In, that also explains how to get this as well.

Here is the content of our gulpfile for reference.

  1. var gulp = require(‘gulp’);  
  2. var gutil = require(‘gulp-util’);  
  3. var spSync = require(‘gulp-sharepoint-sync’); //https://github.com/Fabian-Schmidt/gulp-sharepoint-sync  
  4. var config = require(‘./config.json’);  
  5. var source = “src”;  
  6. var destination = “/Demo/Gulp”;  
  7. var conn = spSync.create({  
  8.     site: ‘https://sharepointknight.sharepoint.com/’,  
  9.     authenticationMethod: ‘ACS’,  
  10.     auth_clientId: config.client_id,  
  11.     auth_clientSecret: config.secret,  
  12.     parallel: 5,  
  13.     log: gutil.log,  
  14.     logLevel: 2  
  15. });  
  16. gulp.task(“deploy-all”function(callback) {  
  17.     var globs = [source + ‘/**’];  
  18.     return gulp.src(globs, {  
  19.             base: source,  
  20.             buffer: false  
  21.         }).pipe(conn.newerOrDifferentSize(destination)) // only upload newer files  
  22.         .pipe(conn.dest(destination));  
  23. }) gulp.task(“watch”function() {  
  24.     var globs = [source + ‘/**’];  
  25.     gulp.watch(globs, function(event) {  
  26.         gulp.src(globs, {  
  27.                 base: source,  
  28.                 buffer: false  
  29.             }).pipe(conn.newerOrDifferentSize(destination)) // only upload newer files  
  30.             .pipe(conn.dest(destination));  
  31.     })  
  32. });  

     

    As you can see our gulpfile is not super complex we are defining two tasks for gulp. The first is called “deploy-all”, this task will sync all the files in the “src” folder and all sub folders due to the “**” with Demo/Gulp folder in the SharePoint site. You can change where the files come from by changing the base value from src on line 5 to whatever folder you use. To change the deployment location, change the value on line 6. This can be an existing folder in a library or if it doesn’t exist the sync will create the necessary structure. The second task, “watch”, will perform the sync as well but it will sync the files as we are changing them instead of forcing us to manually run the task each time. This is the coolest part of the setup. This task gets us the benefits we have discussed. To run this, we need our node.js command prompt. Make sure you are in the root of your project folder and type “gulp watch” This will tell gulp to run the watch task and when we modify a file in the src folder it will pick it up and sync it to SharePoint.

Possible Office365 Issue

I have discovered, working with a colleague, that there is a possible issue that you might run into when deploying to an Office 365 site. If you receive the following error when deploying an aspx page then you need to enable custom scripting on your sites.

StatusCodeError: 401 - {"odata.error":{"code":"-2147024891, System.UnauthorizedAccessException","message":{"lang":"en-US","value":"Access denied. You do not have permission to perform this action or access this resource."}}}

This is because Office365 is trying to secure your site and not allowing custom scripts to be loaded through a manually uploaded aspx. You will get the same error if you try uploading the file any other way as well. Microsoft has provided instructions on how to do this at https://support.office.com/en-us/article/Turn-scripting-capabilities-on-or-off-1f2c515f-5d7e-448a-9fd7-835da935584f?ui=en-US&rs=en-US&ad=US&fromAR=1. Keep in mind that this setting can take up to 24 hours to take effect according to Microsoft, in reality it is a job that runs overnight. After changing this setting, all new site collections that are created will have this setting immediately.

1 thought on “Modern Software Development Life Cycle Part 1”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.