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:

+:refs/heads/feature/*

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.

 

GitFlow and code reviews

Presentation1Many companies that uses GIT as its code repository use git-flow as the branching model for its projects. The question, that one can come up with is where and when the code review should be taken? Should it be before:

git flow feature finish MYFEATURE

If yes, then the reviewer looks through some version of code, but still, the person responsible for closing the feature creates a a new merge commit after all which can change a lot. On the other hand, if the reviewer creates the merge commit, he/she may not know all the aspects needed for a successful merge. There are a few pages trying to answer this, but still I haven’t found anything satisfying. Please read further for my proposal of clean and proper code review process with git-flow.

The problem with git-flow is the fact that finishing a feature is an atomic action. In one action the author does plenty of things

  1. Author: pushes the commit to the remote
  2. Reviewer: reviews the code
  3. A: creates a merge commit (new commit created!)
  4. A: moves the develop cursor to the new commit
  5. A: deletes the feature branch
  6. A: pushes to the remote

As always, splitting one action into multiple and then proper grouping might help. Consider the following flow including the author and the reviewer.

  1. Author: creates a merge commit
  2. A: moves the feature/a to the merge commit
  3. A: pushes the merge commit to the remote
  4. Reviewer: reviews the merge commit
  5. R: if the review is successful, rebase the develop with fast-forward to the merge commit (some automation can be introduced).

According to this flow, the reviewer always reviews the commit which will land in the develop. Additionally, this makes the author of the feature branch aware of merge problems before he/she pushes out his/her work to the review. Effectively, a feature can be completed and merged and simply wait for acceptance which then, is a simple “go/no go” without considering merge conflicts later on.

This isn’t a git-flow anymore, but still, it is a solid flow to lower the context switching of the author. Ones he/she finishes, it’s a real end, not an entry for incoming merge.