Turns out that calling RgPublish from Team Foundation Server (or Service) was harder than expected.
My first approach was to call from the existing default build template. It looked like the property Advanced.Post-build script path in the build definition would be able to do what I wanted, but there were a few problems:
- StdOut doesn’t seem to make it into the build log. (I hope this was just my machine, or an issue with the version of TFS 2013 Preview I’m running.)
- Build numbers cannot be passed in, in this way.
My second approach was to use MSBuild to call the command line. Phil Van Houten recently created some scripts for this, and was kind enough to share them on GitHub.
My third approach is to have a custom build template. While difficult to learn, I found the build template to be the most flexible way to control the build process. It means you can provide fields on the build definition with descriptions and default values.
The templates are based on the TFS default templates, so have all the standard build and test functionality you would expect. There are versions available for both TFS 2010 and 2012. Additionally they have a Red Gate category at the end, with all of the properties you need to provide to publish packages to Deployment Manager. The fields are flexible enough that it will work with any kind of project. For example websites can set the RgPublish source as the folder containing the published website. Web applications can set it to the project file. Databases will soon work in a similar way as well.
The custom templates are available on GitHub. There are versions available for both TFS 2010 and 2012.
The script modifies the build number format to be just the BuildID. The BuildID is an integer that continues to increase, unlike the build revision number that resets each day. The version number of the published package is the value used for Publish version number followed by the build number. Eg. 188.8.131.529. This should be suitable for most cases, but you can always tweak the behaviour as needed.
To integrate the custom template into your build process, you can either:
- Use the templates directly. This is easiest. It’s only possible if you are currently using the default build template, as you’ll otherwise lose any customisations you’ve made.
- Merge the changes into your build template. This is a little bit tricky. You need to make sure the right pieces of XML go in the right places. It’s worth it though, if you’re reusing a custom build template across a number of different projects. The diff is available via the GitHub repository readme.
You’ll need to make sure the RgPublish.exe command line is available to the build agent in some way. You could either copy it to your build agent, or commit it to TFS. You can download the latest version of this command line from the Tools menu in your Deployment Manager installation.
Ideally TFS would have the ability to compose build templates in some fashion. Then we would be able to provide Deployment Manager integration in a drop-in fashion, allowing it to be easily updated too. Activities are close – the logic for calling RgPublish and handling errors could be wrapped into a single custom activity assembly. But template customisations would still be needed to expose properties in a friendly way.
Update: This has now been extended to support DeploymentManager.exe for automatic release creation and deployment. We plan to extend our sqlCI functionality to work in this way too.
I hope this provides a helpful starting point when integrating Deployment Manager with TFS. Please let us know if it is helpful to you, and tell us about problems you encounter or ideas you have for making it easier.