How to experiment with CD in a GitFlow environmentCan we experiment with continuous deployment without completely migrating away from GitFlow first? Here are a couple approaches.
A reader recently asked me if it would be possible to experiment with Continuous Deployment on a project that’s effectively using GitFlow (That is: two long-lived branches, typically called
develop, wherein after some verification, code in
develop is later merged to
main for deployment). I really love this question, because as you may know, I’m a big advocate of experimentation.
So how can we, or even can we experiment with continuous deployment for one team, or a subset of stories, without completely migrating away from GitFlow first?
Here’s my two-part answer:
You could write an automatic deployment script that only applies to certain pull requests. Maybe it looks for branch names that begin with
cd-, or some special token in the PR description such as
However, I wouldn’t actually suggest doing this. Instead, I would set up automated deployments to run on merge. Which could be thought of as the deployment half of CD, or what I call “Lean CD”. Then it’s up to you to decide when (and if) to merge directly into main, bypassing the
developbranch. For some tasks, you could do trunk-based development, and merge frequently (possibly using feature flags). And for other tasks, you could take whatever traditional approach you use (possibly involving manual QA, etc).
If you’re on a team using GitFlow, or a similar branching strategy, and you or someone else on your team is unsure about the impact of implementing Continuous Deployment, this could be a great strategy to dip your toes in the water before making the plunge.
And in the worst case, if you decide not to go forward with all-out Continuous Deployment, you’ll at least have a faster and more reliable automated deployment in place at the end!
Improve your software delivery