Dennis Doomen

Dennis Doomen

On an everlasting quest for knowledge that significantly improves the way you build your key systems in an agile world.

Why I am abandoning GitFlow

Edit this page | 1 minute read

Now that the number of downloads of Fluent Assertions is about to cross the magic number of 1 million downloads, and the library is quite feature complete, it is time to rethink the release strategy. Since its inception we've always used a separate branch for working on future features and improvements, and then used dogfooding before the final release was done. After we switched to Git, GitHub, and PSake, we automated the entire development pipeline and embraced Vincent Driessen's GitFlow as a formal release strategy. In particular, we used to use the develop branch for upcoming features, a release- branch for dogfooding or beta releases, and the master branch to represent what's on NuGet.




Technically, shipping a new version requires nothing more than merging a pull request and tagging a commit on the master branch. Versioning, packaging and everything else that is needed to build a nuget package is completely automated. And there's more than enough unit tests to guarantee the quality, so dogfooding is an exception these days. The only thing left is to create some release notes, but even that can be automated these days. 

The fact of the matter is that new releases of Fluent Assertions aren't as massive as they used to be. We still get feature requests and run into occasional bug fixes obviously, but they are relatively small and have low impact. For the same reason, we're not working on the project as active as we used to be, so collecting all improvements until it's time for a major release doesn't make sense anymore. 

So as of today, we'll be shipping releases of Fluent Assertions much more often, albeit with a lot less changes as prior releases. In essence, we will be practicing a form of GitHub Flow (but without the deployment part). We'll still use Semantic Versioning, so you will be able the impact of the releases from the version number. 

So what do you think? Do you agree with my decision? Let me know by participating in the Disqussions below. And please follow me at @ddoomen to get regular updates on my everlasting quest for better solutions.

Leave a Comment

You May Also Enjoy

Should architecture be constrained by reality?

4 minute read

Should architects make decisions with the constraints of available capacity in mind? Or should they strive to ignore the reality and pursue only the best solutions?

April 28, 2019

9 tips to get your distributed teams to collaborate effectively

9 minute read

I’ve seen a lot of prior attempts to out-source work to remote teams fail, have always wondered what was the main reason for this. Is it a culture thing? Is it the time difference. In this post, I describe the things we do ourselves that have made our remote team endeavors pretty successful for t...

March 4, 2019

A surprisingly accurate model to improve your communication skills

7 minute read

It may be coincidence, but the two best tutorials I attended at Agile DevOps East both ran on the same day. The first one focused mostly on agile transformation, but briefly touched on the leadership topic. This one, let by Jennifer Bonine, took this further by focusing on being a better leader b...

November 11, 2018

About smooth agile transformations and the “why” leader

3 minute read

For my annual conference trip, I decided to skip the always-great QCon conference for once and instead attend Agile DevOps East in Orlando, Florida. In addition to the typical conference schedule, I also registered for some of the half-day and full day tutorials. One of them, How to lead high-per...

November 7, 2018