Now that all the components are RTM, I thought I would put up a post about how I'm using the new build and release systems present in 2015, to deploy successful builds to our QAT environment.

Background

This isn't the first time we have tried to do automated deployments for our solutions, however with over 50 projects and a XAML build definition complex enough to make grown men cry, it was more trouble than it was worth. As an example the last time we updated the XAML definition it took almost 3 weeks to get it to work properly.

Enter Build Vnext

This was the crucial component that has allowed us to follow a more automated release path, our horrid XAMl build definition, which would almost crash Visual Studio if you even looked at it funny, has been replaced by this....

If you didn't know I love PowerShell, which makes me very happy with the new build system. All of the previous complexity of our XAML definitions has been replaced with clean reusable PowerShell scripts, which unlike the old build definitions are properly source controlled!

Getting the builds replaced with the new build system was actually really quite simple, and had the added benefit of revealing some obscure issues with our build process that had never been detected with the XAML definitions.

SharePoint 2010

At this point you are probably wondering what this has to do with SharePoint 2010. If you didn't know, SharePoint is what I do for a living, working on a custom learning platform built on top of SharePoint 2010. As I've never mentioned it before, to give you some idea of the scale of our platform; we have over 1M+ active subscribers from 140+ countries, we use over 1M lines of custom code to tune SharePoint to our needs, we operate 24/7 X 365 with an uptime over 99.99%. While it was possible to manage this all manually, which I did for many years, as our teams grew internally it came to a point where I was spending most of my days simply managing the builds and releases being generated by our developers.

Release Manager 2015

We first tried to utilise release manager with our SharePoint solutions with the 2013 release, however due to various complexity within our environment (TFS/RM in a different domain to all the servers etc) the agent based release simply never worked, or required so much manual intervention that it was of no benefit.

PowerShell to the Rescue

Did I mention I Love PowerShell! thankfully the 2015 release included the new agentless release paths, which rely on PowerShell instead of an agent. This meant I could simply adapt a few of our already present SharePoint deployment scripts, and have RM run them for us.

I must say this was actually harder then I was originally anticipating, the issues starting as soon as I tried to run a script against one of our dev servers.

The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered.

I should have clocked this would be an issue beforehand, as of course RM was running the commands on the latest PowerShell, but SharePoint 2010 cmdlts only support V2. In order to resolve this issue I wrote an intermediary script which relaunches the process in PowerShell V2 once it comes to talking to SharePoint.

Where is the Documentation??

This was the biggest pain throughout the process, in that none of the documentation had been updated for 2015. The only information I could find was one blog on initiating releases from team city, that mentioned some of the new bits he had discovered, but unfortunately even these were not entirely accurate due to some changes for RTM. Below are some things to watch out for

• The API version changed to 6
• The deploymentPropertyBag definition has changed
• You must now specify the StageId instead of name

Getting the stage id turned out to require a few invoke-restmethod calls back to RM to get the correct values. but once those were sorted (which took a few days to figure out) everything fell into place.

The End Result

Having got everything up and running, RM now successfully deploys over 40 of our SharePoint solutions as part of our CI builds. We haven't quite got every single part included yet, but shouldn't be to hard now we know how it works.

Want more?

If anyone would like more detail around a specific area of this configuration, drop a note in the comments and I'll see about getting it written up.

Update - Link to example

As requested, here is a link to the release script example.
Unfortunately, I no longer have access to a TFS/RM setup to test the script. But it should give an idea of how it works.