Sympraxis’ SharePoint Client Side Development Pipeline – Introduction

4 minute read

As promised in our August Sympraxis Newsletter, Julie and I wanted to start a new blog series to explain our new SharePoint client side development pipeline. We’ll each put our own spin on the idea, as our ways of thinking, backgrounds, and blog focuses are a bit different (but totally compatible!), so be sure to check Julie’s take as well.

We worked a lot in July and early August to improve our development practices in general. Julie joined Sympraxis with some great ideas, and she’s managed to teach this old dog quite a few new tricks. We’ve got all of our current client projects up on private Github repositories and we’ve got a really nice workflow going now that both improves our efficiency and gives us far better disaster recovery capabilities.


This isn’t the pipeline we’ll use when the new SharePoint Framework (SPFx) is released in Preview (hopefully soon!), but it borrows from some of the tech used in that process. If you’re still doing client side development that you plant in SharePoint pages with the Content Editor Web Part (CEWP) or the Script Editor Web Part (SEWP), then this pipeline process will prepare you for some of the things you’ll need to understand when you get to SPFx.

We edit our client side code on our devices (laptops, tablets, even phones!) in local copies of the repos, use gulp tasks with spsave to push changes to the Office 365 or on premises tenant, and then commit blocks of changes to the Github repos.

Gulp logo

We’re even using different IDEs to work on our code. Right now my favorite is WebStorm, whereas Julie prefers Visual Studio Code. Because the tooling we used all sits on top of nodejs – which is truly cross platform, cross IDE, cross everything – it doesn’t really matter that we’re using different IDEs.

Webstorm logo

If you’ve been using source control for a long time, this may seem like old hat to you. But for many client side devs (like this old goat), there haven’t been very good ways to do it effectively. The old “map a local drive and edit the JavaScript/HTML/CSS in place” method has been good enough for years. But with the newer Document Library “experiences” on Office 365, the trusty Open with File Explorer is starting to work unreliably. Besides, it was time to get with the program.

For years now, my “pipeline” has been to map a drive to my code repository in the client tenant or installation, edit the files in place, and all was good. I’ve gotten in the habit of storing my code artifacts in one of two places:

  • ScriptsCSS – This was my practice for quite a few years, and is simply a Document library – usually in the root of the Site Collection – where I put things. Because it’s a Document Library, I can turn on versioning if I choose, restrict access for write (though everyone needs read permissions to access the code), etc. It’s also in “plain sight” for the people I work with at the client. This is usually a *good* thing, but more recently I switched to using…
  • /_catalogs/masterpage/_ClientName – This is a bit more out of the way, as it means putting my code in the Master Page Gallery. If permissions are set correctly, this means that few people can accidentally wander into it, and everyone has read access by default.

Either of these locations work and have worked for me regardless the version of SharePoint, whether it be 2007, 2010, 2013, 2016, or any flavor of SharePoint Online. My original goal with all of this was to avoid deploying ANYTHING to the server. It just so happened that this goal ended up meshing with where Microsoft has come over the years.

My reversion technique was simply Ctrl-Z (undo) in my editor of choice. If I had versioning on in the Document Library, then the version history was available for me, too. As for IDEs, sometimes I use SharePoint Designer, sometimes Sublime Text, sometimes WebStorm.

One of my other approaches to “working in production” (a collective gasp goes up from most people) was to create copies of the “prod” files I was working with – maybe something like HomePageNEW.ASPX, HomePageNEW.html, HomePageNEW.js, etc. This gives me a way to work on the next version of everything while still using the same content base. In cases where there are content updates, I may even have a whole shadow set of lists and libraries for testing. Having them in the same location makes it easy to copy content back and forth – usually using Sharegate, of course! I still do this, but now with better source control I have a better record of whence I’ve come.

None of these practices are really source control. Sure, I would ZIP everything up once in a while and store it away, but I couldn’t get back to a specific point in time. My approaches *worked* but weren’t as robust as I would have liked.

In the rest of the series, Julie and I will explain how we arrived at our new approaches in our posts, how they work – in detail, with code! – and what we get out of it. If you have specific questions, please feel free to add them in the comments and we’ll attempt to cover them. And don’t forget to read Julie’s spin on it, too!


Series NavigationSympraxis’ SharePoint Client Side Development Pipeline – Where Should We Put Our Stuff? >>


  1. Gulp alright! I’ve just spent 3 weeks googling like a madman to choose a suitable build tool and now you’re introducing more options! One of these days I might actually get around to building something with these build tools…

  2. Ugh! Trying to get this going with Visual Studio Code and I just don’t know enough to troubleshoot why I keep getting “Cannot find module ‘spsave'” when I attempt to run my gulp task.

    It appears in the documentation that you simply declare:

    var spsave = require(‘spsave’).spsave;

    However, it just doesn’t seem to want to find the module even though I can see it sitting right in the node_modules folder. I’m hoping the next set of articles will help explain getting this to work.

  3. Hi Marc,

    Thanks for this post. I’m very excited on the updates here as I recently started doing more of a client side development SharePoint. I was used to doing things in Visual Studio and while using either TFS or Github for our source control. Deployment, development and testing were all straightforward. However, now that I started working with SharePoint Online with limited access to some places and with side loading of apps currently disabled it seems like I can no longer do the typical “workflow” that I was used to.

    I’m not sure if you’re going to discuss it in detail in your succeeding posts, but I’m interested and wanted to get your input/suggestion on my current development workflow. What I do is create a folder under site pages and store everything there (with respective folder names of course). This is all well and good if you’re working in a small team (2-3 people). You can easily do modifications on the code then test it out on the SharePoint site. But what should we do if we wanted to do testing locally prior to deploying it to the SitePages?

    From what I have currently tried, I’m unable to call REST Calls locally and keep getting 403 errors so I’m not sure if this part of the local development and testing would even make sense. Maybe you can help guide or point me in the right direction on where to look as it seems to me like I might have missed some things which might be causing this.

    Again, I’m excited for this post series and hope to read more from this development pipeline of yours.

    PS. I’m also waiting for a detailed SPFx post once it’s been released.

    Thanks! :)


Have a thought or opinion?