,
24 tweets,
9 min read
Read on Twitter
Hi @InfoQ, your #GitFlow article is flat out wrong. It is 100% incompatible with #ContinuousIntegration and #ContinuousDelivery. continuousdeliveryconsulting.com/blog/organisat… / @danielbryantuk
Here's an @InfoQ article I did in 2015, explaining why #GitFlow is incompatible with CI let alone CD infoq.com/news/2015/10/b…
Here's an @InfoQ video of a talk I did in 2015, which includes an explanation of why #GitFlow is incompatible with CI infoq.com/presentations/…
Now for the article itself...
"GitFlow... exploits the power, speed and simplicity of Git branching"
Wrong! GitFlow is neither fast nor simple
Wrong! GitFlow is neither fast nor simple
"Documentation for using Gitflow in a CI/CD pipeline is nebulous at best"
1. It's not a CI/CD pipeline, it's a deployment pipeline. CI is a team practice, CD is a set of principles & practices
2. Reputable docs on GitFlow with CD are as likely as docs for landing a 🛬 on a 🍦
1. It's not a CI/CD pipeline, it's a deployment pipeline. CI is a team practice, CD is a set of principles & practices
2. Reputable docs on GitFlow with CD are as likely as docs for landing a 🛬 on a 🍦
"Given the well-known branch names - master, develop, feature, etc., which branches do we build, which do we test, which do we deploy snapshots, which deploy releases"
Snapshots are incompatible with #ContinuousDelivery. They are not reproducible
Snapshots are incompatible with #ContinuousDelivery. They are not reproducible
"Continuous Integration is... the practice of building and integrating code in an automated fashion, every few hours"
Nope. It's where every team member commits to master/mainline at least once every 24 hours. And that's impossible with #GitFlow, even if you automerged Develop
Nope. It's where every team member commits to master/mainline at least once every 24 hours. And that's impossible with #GitFlow, even if you automerged Develop
"Master is referred to as a stable branch - containing only work that is production ready, either released or ready for release"
This is completely opposed to CI and CD, which both advocate master/mainline always containing the latest commits and in a releasable state
This is completely opposed to CI and CD, which both advocate master/mainline always containing the latest commits and in a releasable state
"Development now proceeds in parallel, everyone working on their feature branches concurrently, some teams working on the same branch completing that feature, others working on different features"
My head hurts thinking about the dependencies, merge conflicts, and slow feedback
My head hurts thinking about the dependencies, merge conflicts, and slow feedback
"In the spirit of continuous 'integration' we want to ensure it plays nicely with all of the other team feature commits. So by policy we agree that all development teams merge to the develop branch at least once per day"
What if that was done on master, and you actually did CI?
What if that was done on master, and you actually did CI?
"Finally, after some number of days, the feature is complete, it is fully merged into develop and declared stable"
So... not CI or CD then. You still have to merge into master from develop, and that'll be another round of merge hell
So... not CI or CD then. You still have to merge into master from develop, and that'll be another round of merge hell
"At this point we branch a release branch off develop"
🤦♂️
🤦♂️
"And at long last we merge to master"
At long last indeed
At long last indeed
The advantages of this approach are either inaccurate, not specific to #GitFlow, or unadvantageous
"Features are isolated – it is therefore easy to manage your own feature changes in isolation"
Unadvantageous. #GitFlow optimises for the individual, not for the team. Feature isolation at the code level to this extent makes CI and CD impossible
Unadvantageous. #GitFlow optimises for the individual, not for the team. Feature isolation at the code level to this extent makes CI and CD impossible
"Feature segregation, which lets you decide which features to include in a release"
You're better off using config to select features at run-time, not compile-time. Then you can Dark Launch, you can gracefully degrade, you can test in production, etc.
You're better off using config to select features at run-time, not compile-time. Then you can Dark Launch, you can gracefully degrade, you can test in production, etc.
"Promotes continuous integration and frequent commits"
This is just wrong. Frequent commits to any branch other than master/mainline is unrelated to, and even opposed to #ContinuousIntegration
This is just wrong. Frequent commits to any branch other than master/mainline is unrelated to, and even opposed to #ContinuousIntegration
"Promotes clean coding"
Is that still a thing? You can do that with or without #GitFlow, if you really must
Is that still a thing? You can do that with or without #GitFlow, if you really must
"Automated testing, deployment and release to all environments"
You can have those nice things with any version control strategy as they are post-build. With #GitFlow, the feedback loops will be awful
You can have those nice things with any version control strategy as they are post-build. With #GitFlow, the feedback loops will be awful
Data: in a 2017 talk, I showed how measuring mainline commits indicated CI/CD success. I had a real world Team Pears example with 1 master commit every 4 days became 1 a month. That was #GitFlow. Other teams fell into the same abyss
Data: @tdpauw has covered this topic in great detail as well
My original in-depth article on why #GitFlow is incompatible with #ContinuousDelivery is continuousdeliveryconsulting.com/blog/organisat…
