I enjoy sharing practices amongst various teams. The discussion about what works well, what could be done better and actions that others have taken help us all reduce friction. One piece I wanted to share, with hopes of inspiring others to do the same, is what we are doing with our continuous integration pipeline for one of the projects I’m working on. We use JetBrains TeamCity to manage the delivery pipeline, but more important than what tool you use is how you view its responsiblility. The role of a CI server, in my view, is to coordinate the stages in the pipeline and check for success before proceeding to the next stage. The details behind the activities are kept separate from the CI server in a make file that is checked in with the code. This enables team members to run the steps locally to troubleshoot or replicate issues happening on the build agent.
The basic pipeline we use looks like this:
The CI server supplies the version number to build, path to the source control repository, and the TargetProcess release name to add the build under. The rest of the details are stored within the build script itself.
Branches and Builds
The team I am working with uses Subversion at the moment with an eye towards Git for the latter half of the year. The web application is deployed into a managed environment and so we need only to focus on what we are building next and the last deployed version. Our typical branch structure looks like:
- branches/1.x - current production release
- tags - point in time references to previous releases
- trunk - next release
When we promote the 2.x release stream to production we’ll have a 2.x branch that will maintain the current 2.x release code and remove the 1.x branch. We don’t rename the branch for every minor or hotfix release to reduce the amount of devops works. This translates into the build configurations being duplicated for each branch (which is easy right now):
- 1.x-Integration Test
- 1.x-Deploy To Test
- 1.x-System Test
- trunk-Integration Test
- trunk-Deploy To Test
- trunk-System Test
What Does Your Team Do?
While I am most interested in TeamCity, but if you use Team Foundation Server, Go, CruiseControl, Jenkins I would be equally interested in hearing how you structure your build pipeline.