Archive for October, 2012

Automating SharePoint Build and Deployment–part 1

25 October 2012 2 comments

Over the last twelve years of my career I’ve been part of a service delivery company that delivers software, both bespoke and packaged, to hundreds of customers every year.  In all of these projects there are some common tasks and frameworks that we have created to build and deploy our products.  In so doing it has improved the quality of the products we deliver, so I think it is worth sharing my experiences with building them.

This article, and the ones following, aren’t about those frameworks.  I’m not going to tell you how they work, and I’m not going to give you the code (so don’t ask).  This is because of a number of factors, but the key one is, it is out of date and it is using deprecated features of the current versions of Microsoft Team Foundation Server (TFS) and other tools.

This series is going to be about the guiding principles and techniques we have used to extend this framework so that we can do automated builds, and deployments, with SharePoint.  I’m hoping that, 1. we can understand what we have so we can update it and 2. that you, the reader, can improve your environment using these thoughts.

The toolset

Before I continue it is probably worth mentioning the tools we have used to build our framework, even though the principles in this series can and should be applied to any other tools that perform a similar function.

  • Microsoft Team Foundation Server – this is used primarily as a source control repository but the TFSBuild components are critical to in the build stage, which I’ll leave for the subject of another post.
  • TFS Deployer ( – this is a codeplex project that monitors the builds happening in TFS and triggers scripts based on changes to the build quality, result, etc.
  • MSBuild – Visual Studio, and obviously TFSBuild, use this behind the scenes to do the actual compilation of the code.  We use this to package the build output and sometimes as the scripting language for the deployment, again I’ll leave that subject for another post.
  • PowerShell – The ultimate scripting language for managing Microsoft technologies and products.
  • SharePoint 2010 – Ok so I almost forgot that one.  The fact that we deploy against this does not mean that we cannot use a different version.  It is just that from 2010 SharePoint had really useful PowerShell commandlets to help.  SP 2013 will work just as well using this broad approach, MOSS 2007 will require some changes on the Deployment step.
    You probably noticed that these are all either Microsoft technologies or built on Microsoft technologies.  That is because I work in the Microsoft Solutions team, and also because the point of this series is deploying to SharePoint (which is itself a Microsoft product).  This doesn’t mean you can’t substitute other tools but we have chosen to use this set.

Why automate?

It is important to define the goals behind this automated process.  Otherwise we could end up automating everything but achieving nothing instead of focusing on the important areas to automate first.

The goals are simple:

  1. Save time – No one likes doing the same thing over and over.
  2. Reduce errors – If it is automated there is less chance of forgetting something or doing it wrong.
  3. Save cost – By achieving a time saving and reducing the rework from errors we’ll automatically save costs. However, the time taken to introduce the framework to the next project that uses will also save costs, which can be directly passed onto the customers.

How and what are we automating?

The short version is that we are automating everything to do with building and releasing the software.  As soon as a developer checks in some code we want to be able to have that built, deployed onto a SharePoint farm and tested, before we tell the tester that they can have a look. 

At least that is the dream.  To realise this dream, and I haven’t quite got there yet, we have to break down the problem into small tasks that can be automate it.  Automating the entire process will be accomplished by building smaller automated pieces and then automating the running of these smaller pieces.

So lets break it down a little, which will also guide the structure for the rest of this series.

After many attempts at defining the parts of the framework we have settled on three broad areas for automating, these are:

  1. Build – The building of the source code, versioning the assembly outputs, signing etc.
  2. Package – The packaging of the build outputs into something that can be deployed.
  3. Deploy – The deployment of the package created in the above step.
    The main objective is to automate the deployment post shipment.  Thereby reducing the length of time it takes to write installation instructions, but also to reduce the errors that invariably occur when the Infrastructure people attempt to install our software, and if an error occurs, then reduce the time it takes to determine what where it went wrong.
    Therefore all the steps work toward meeting this objective, the first two steps to build and create the package, the third tests it before shipment, and controls the release post shipment. 

As in order to define the package we need to know what the deployment looks like we will start by investigating what we need to deploy SharePoint solutions.  And then as we progress through the series work backwards through the package and build steps.

There are of course other approaches for doing this, in fact, when we come to update our framework we will probably lean heavily upon them.  The most notable is Chris O’Brien’s series on SharePoint 2010 Continuous Integration, however our framework does some things differently so we will need to make some changes to that approach.

But that is enough of an introduction, in the next post we will look at the structure of the deployment package.