Automating and optimizing the processes I use everyday to work is something important so that I get more productive and spend less time in things that a computer is better at.
Previously I had 3 builds defined in TeamCity one for all feature branches, one for release and one for patch. For feature branch and patch branch I needed to go to TeamCity to define two Build Parameters: the branch name and the release number.
My goal was to avoid to go to TeamCity when we have a release and have to set those Build Parameters.
I wanted one TeamCity build which would
- Determine automatically the version number
- Determine the branch to use to build that release
The second point was easy! You just need to follow the same principles defined for feature branches. I defined the following branch naming convention: any release should have a branch name like this release/skye-editor-2.26.0 for a release of Skye Editor 2.26.0. Then I defined in my VCS Root of my TeamCity Build the branch specification:
and the same for the Build Triggers / VCS Trigger / Branch filter.
Now the first point is a bit more complex!
As we want to determine automatically the version number we quickly realize that the release number is defined in the branch name itself, e.g. release/skye-editor-2.26.0.
So why not use it? Yeah great idea but how?
First idea that came was to pass that value as a parameter to the build script and deal with splitting the branch name to the release number into the build script. As Yegor was confirming that currently TeamCity has no way to parse values. I didn’t really like that idea of passing that parameter! So I continued to think about alternatives and finally came to ask Yegor:
I had another idea, in teamcity when the active builds are displayed for a feature branch build only the second part is displayed, e.g. if I specify as branch specification SKYE-* and I have a branch with SKYE-1077-blabla then it wil show 1077-blabla. Is there a build parameter which would map this 1077-blabla?
And the answer was
If you have something like refs/heads/SKYE-(*), then only the part in the brackets is regarded as logic branch name. Logic branch name is available as %teamcity.build.branch%
That’s it! Thanks Yegor. We have the way to get our version without having to change our build script and without writing any code!
So I just used the logical branch name %teamcity.build.branch% as my configuration parameter CurrentRelease which was already existing and that I had to manually update before:
Replacing the previous two manual configurations
So now I create easily a Git release branch; release/skye-editor-2.26.0, then use pull requests of Atlassian Stash to review and merge my feature branches to that release branch which is automatically built using TeamCity.
This is a great improvement and shorten my release check list, all good!