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

Event Sourcing in .NET - Using an OR/M as a projection library

9 minute read

I thought we didn’t need OR/Ms anymore? A common advantage of adopting Event Sourcing is that it solves the impedance mismatch between object oriented code and the relation database model. And because of that, Object/Relational Mappers (OR/Ms) have become obsolete. While I agree with the first st...

July 15, 2018

Event Sourcing in .NET - Building fast autonomous projections

12 minute read

The characteristics of a great projection implementation Over the course of the last two years I’ve written numerous articles on the good, the bad and the ugly of Event Sourcing as well as on our experiences building and maintaining a distributed enterprise-class based on this increasingly popula...

May 18, 2018

Don’t blame the dependency injection framework

12 minute read

Over the last couple of months I’ve heard and read quite a few statements that say that Dependency Injection frameworks are bad things that you should avoid like the plague. In my opinion that’s just a result of rejecting something because it has been misused too long. Don’t get me wrong. I’ve be...

May 2, 2018

The Red Hot Developer - A model for removing distractions from your teams

4 minute read

When your project, product or component gets sufficiently big that it has a large impact on the rest of the organization, you’ll automatically get faced with lots of internal and external distractions. Other teams might want to get that pull request merged as soon as possible, all kinds of questi...

March 23, 2018