GitFlow and Continuous Build

In the recent post I’ve described the idea how to ensure, that your feature-to-develop GitFlow merge commits are reviewed before being introduced to the develop branch. This preserves the quality of the develop branch, ensuring that it’s truly possibly deployable. How one would like to build his/her repository and provide artifacts? Which commits and which branches should be built? These questions are answered below.

Let’s start with the following observation. Whichever branch points at the given commit, if a proper modern build approach is used like PSake build script is used, the result is the same. The repository contains all the needed scripts to run the build, the output will be the same no matter which branch is selected as a source of the build (if two or more points at the same commit). After all the same commit is the same tree which results in the same build. This gives us a very powerful tool in ensuring even better quality of develop. One can easily setup TeamCity using branch selector to run the same build for all features:


The build script creates artifacts, in my case NuGet packages, using the following versioning [major].[minor].[build_number]. The first two are the numbers stored in the repository. This requires that features are not long running (you don’t want to have a long running from 1.1.1 to get to later than 2.1.2). The build number is the same for all the features. For now, I’m not considering case whether the artifacts should be published to some gallery or not.

The question is, should we build the development commits? For now, considering only the feature branches, the answer is no! All the commits in the develop are merge commits which have been already reviewed and build in the feature branches! That’s why creating the merge commit in the feature is so powerful. You get the code reviewed, built and tested before it goes to the development! Again, the idea of postponing finishing a feature till it has its value acknowledged bring profit to the quality of the develop branch.


Continous delivery of an open source library

In the recent post I’ve dealt with a basic setup of git branching protecting an open source library author from a headache of not-so-production-ready master branch of a repository. Having two main branches setup (master & dev) one can think about introducing continuous delivery. How about automatic publishing any set of commits getting into production branch? TeamCity with its git support made it trivial.

The very first build configuration has been made for dev branch. The target branch was dev branch. It consists of only two steps:

  1. Build – done with MsBuild
  2. NUnit – running all the tests

The second was a bit longer, based on the master:

  1. Build – done with MsBuild
  2. NUnit – running all the tests
  3. NuGet pack – preparing a NuGet package with mixed NuSpec + csproj of the main library
  4. NUnit publish – pushing the prepared NuGet to the NuGet gallery.

As the master branch is considered as production ready, in my opinion, there’s nothing wrong with creating and uploading NuGet package for each set of commits, which goes through the tests. The very last case is versioning. For now (KISS), it’s based on the master branch build number preppended and appended with 0. This generates 0.1.0, 0.2.0, 0.3.0, etc.

Continuous delivery

I’ve just finished a Continuous delivery book. I must say, that my expectations were much higher than the level at which the topic was described. I do not say, that this is a bad book, but having a few well-grounded articles, like Fowler’s I simply do not find it good enough for a deep dive into the problem’s space. The last chapters present a way in which the whole book should have been written: simple cases with a short explanation dealing with the most common problems. From the other side, the very first chapters repeat like some kind of mantra the same sentences paraphrised over and over again (automate your build, do nothing manually, etc.).

If you’re a noob, and read nothing about this topic, that’s a very good choice. For the others: it is not a must-have.