benrobb's blog

This series of blog posts is taken from a session I delivered at the SharePoint Conference 2008, in March.

Part 1: Why would you want to have build automation in SharePoint Solutions?

For simple solutions, where you have little custom code, and a single, linear set of projects, you can get away with not formalising your deployment process. However, if you have a large intranet or public facing site, you will probably be faced with a solution which has:

• Frequent changes to functionality.
• Multiple teams working on different streams
• Cross-project dependencies
• Different release schedules
• Tight control over the production environment.

A typical site will probably start off being simple: a foundation project will determine the network topology, it will do the initial build and configuration of the servers, and it will have the initial development of the core components of the site – a master page, some custom controls and some page layouts and CSS. Typically this will have a single team of developers working towards a "big bang" launch. All being well, they will launch the site and have a few beers to celebrate. If they are contractors, or working for an agency, they may well go off to other jobs.

But then what? 

On a large scale website, that's never the end of the story. Large websites will never stay static: either in their content or their functionality. There will be ongoing maintainence and bug fixing. There will be change requests to amend the existing functionality. There will also be brand new requirements to provide the site with completely new features.

Programme managers would, in an ideal world, see that these projects are carefully managed into phases, and ensure that each code drop goes through the same process as the first phase. Developers would work together to build their bits of functionality, and then at the end, have integration and testing tasks to form a release schedule. But back in the real world, how does this actually pan out? When bugs are found post launch, your team may well have SLAs to meet. Regardless, you need to fix the problem as quickly as possible. That means that you need to deploy your fixes to your site while your other projects are still running, and often while those projects have breaking changes to your site. This means that you need to start branching your code base – potentially in your configuration management, your file system / .NET assets and your SharePoint artefacts.

Branching

Branching is often feared by developers, but there are some key lessons which should be learnt when determining your branching strategy. This primer on branching and merging, from MSDN explains how different strategies can affect your team, but the bottom line is that you need to think carefully about your branching strategy. If your merges are taking too long (i.e. you have developers sitting round doing nothing for a week), then you are not being granular enough. You need to branch only when you really need to, and merge as soon as possible back into the main build. Leaving your merge to the end of a project is asking for trouble.

Automate your builds 

There are a number of key reasons why build automation should save you time in the long run.

1. Leaving deployment testing to the end of a project increases the risk of it going wrong.
2. Having regular builds means you test your deployment every night, rather than only a couple of times through the project. This means that deployment issues are flagged early in the dev cycle.
3. You can easily ensure that your dev teams are always working with the most up to date version of the build.
4. You can implement Test Driven Development techniques to aid integration testing and regression testing.

These advantages may not pan out so much with the initial build of a site, but as you move on to maintain and enhance that site you really need to make sure you start taking advantage of build automation. 

Build masters

How is this going to affect your teams? What you need to do is create a new position within your team – a build master – to manage the deployment and builds. That person needs to know where all the branches are, what the deployment schedule is and every detail about the solution. This is a key, pivotal role in your project team, and should be senior. This is probably not something that can be fitted in around other work, and could well be a full-time job.

Really big projects which themselves contain branches may require additional build masters.

Now that the scene is set, in the next few posts I will walk through some examples of how to use MSBuild tasks, together with TFS, to automate your builds. 

This entry was posted on Monday, March 10th, 2008 at 8:07 am and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

This series of blog posts is taken from a session I delivered at the SharePoint Conference 2008, in March.

Part 1: Why would you want to have build automation in SharePoint Solutions?

For simple solutions, where you have little custom code, and a single, linear set of projects, you can get away with not formalising your deployment process. However, if you have a large intranet or public facing site, you will probably be faced with a solution which has:

• Frequent changes to functionality.
• Multiple teams working on different streams
• Cross-project dependencies
• Different release schedules
• Tight control over the production environment.

A typical site will probably start off being simple: a foundation project will determine the network topology, it will do the initial build and configuration of the servers, and it will have the initial development of the core components of the site – a master page, some custom controls and some page layouts and CSS. Typically this will have a single team of developers working towards a "big bang" launch. All being well, they will launch the site and have a few beers to celebrate. If they are contractors, or working for an agency, they may well go off to other jobs.

But then what? 

On a large scale website, that's never the end of the story. Large websites will never stay static: either in their content or their functionality. There will be ongoing maintainence and bug fixing. There will be change requests to amend the existing functionality. There will also be brand new requirements to provide the site with completely new features.

Programme managers would, in an ideal world, see that these projects are carefully managed into phases, and ensure that each code drop goes through the same process as the first phase. Developers would work together to build their bits of functionality, and then at the end, have integration and testing tasks to form a release schedule. But back in the real world, how does this actually pan out? When bugs are found post launch, your team may well have SLAs to meet. Regardless, you need to fix the problem as quickly as possible. That means that you need to deploy your fixes to your site while your other projects are still running, and often while those projects have breaking changes to your site. This means that you need to start branching your code base – potentially in your configuration management, your file system / .NET assets and your SharePoint artefacts.

Branching

Branching is often feared by developers, but there are some key lessons which should be learnt when determining your branching strategy. This primer on branching and merging, from MSDN explains how different strategies can affect your team, but the bottom line is that you need to think carefully about your branching strategy. If your merges are taking too long (i.e. you have developers sitting round doing nothing for a week), then you are not being granular enough. You need to branch only when you really need to, and merge as soon as possible back into the main build. Leaving your merge to the end of a project is asking for trouble.

Automate your builds 

There are a number of key reasons why build automation should save you time in the long run.

1. Leaving deployment testing to the end of a project increases the risk of it going wrong.
2. Having regular builds means you test your deployment every night, rather than only a couple of times through the project. This means that deployment issues are flagged early in the dev cycle.
3. You can easily ensure that your dev teams are always working with the most up to date version of the build.
4. You can implement Test Driven Development techniques to aid integration testing and regression testing.

These advantages may not pan out so much with the initial build of a site, but as you move on to maintain and enhance that site you really need to make sure you start taking advantage of build automation. 

Build masters

How is this going to affect your teams? What you need to do is create a new position within your team – a build master – to manage the deployment and builds. That person needs to know where all the branches are, what the deployment schedule is and every detail about the solution. This is a key, pivotal role in your project team, and should be senior. This is probably not something that can be fitted in around other work, and could well be a full-time job.

Really big projects which themselves contain branches may require additional build masters.

Now that the scene is set, in the next few posts I will walk through some examples of how to use MSBuild tasks, together with TFS, to automate your builds. 

This entry was posted on Monday, March 10th, 2008 at 8:07 am and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.