Team Building shelvesets

With our smaller development team, we decided to try and minimize the number of branches we use to simplify our merge/release process. One drawback we ran into is how to handle pushing out an emergency fix when we’ve already got changes being tested by QA in trunk (our integration branch, for all intents and purposes). We could merge the change into the Release branch (a branch that contains code that’s already been deployed to Production and gone live) and check it in, but the idea of release is to only check in once it’s verified by QA and deployed.

Another solution is to have an interim branch between trunk and Release, a production integration branch of sorts. This adds extra complexity by having another merge to another branch you’re responsible for.

To work around this, we decided to merge to the Release branch but rather than performing a check-in, we shelve our changes. We have set up a teambuild that will get the latest source from Release, unshelve a shelveset, build the newly modifed code, and then undo the shelveset. Can’t remember where I yanked it from, but it simply involved adding the following targets to our build .proj definition:

<Target Name=”AfterGet”>
<Exec WorkingDirectory=”$(SolutionRoot)” Command=””$(TeamBuildRefPath)” unshelve “Shelveset build test”;mcooper” />

<Target Name=”BeforeDropBuild”>
<Exec WorkingDirectory=”$(SolutionRoot)” Command=””$(TeamBuildRefPath)” undo /recursive /noprompt $/” ContinueOnError=”true” />

Now all we have to do is merge to release but don’t check in, shelve the changes, and update the proj file to have the shelveset name and owner before kicking off a build.

Leave a Reply

Your email address will not be published.