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 main and 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:

1. 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 #CD.

2. 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 develop branch. 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!