
Ask HN: Best branching strategies for continuous delivery? - ljoshua
We&#x27;re starting up a greenfield project delivering a web-based product meant for rapid iteration. We&#x27;re using Git, and our team of about 5-6 devs all have had experience with different branching strategies in the past.<p>When aiming for a really smooth and testable CI&#x2F;CD pipeline, what approaches combining branching strategies and pipeline tools have you had the best experience with? Feature branches merged right back into master? Gitflow-like approaches? Dev versus master branches? Circle, Bamboo, CodeDeploy?<p>We don&#x27;t want to overcomplicate things, but we do want to be able to test in staging, for example, and keep the number of buttons and procedures required to a minimum. Would love everyone&#x27;s thoughts and war stories!
======
karmakaze
With a team that size, I'd say let them choose whether to develop on feature
branches or master. CI would test each commit/merge to master and each one
that passes is eligible to have the 'staging' and 'production' branches
advanced to it with one button (that should be pressed by the person who is
committing to monitor production following the deploy).

Also plan for a hotfix to production path in cases where a commit is non-
revertible (e.g. one-way migration) and a confident fix is available but time
waiting for CI may not be. Or better yet, always make your tests run in a
minute or two.

What we used at my previous startup was a CI pipeline per microservice with
stages for build/test, staging test/deploy of service, journey test in staging
fully deployed, prod test/deploy of service, and journey test in prod fully
deployed.

A journey test is the top 10 or so things that a user should be able to do
(e.g. sign-up, do a primary thing, do another core thing, get a notification,
tell a friend to sign-up). No matter how bad a deploy is, if the journey test
passes, at least you know that's it's not _that_ bad, or if it fails you know
it right away. One downside is that it runs _after_ deployment so it's a live
issue. (Checking pre-deploy is a false sense of security.)

------
aketchum
We run a feature branch -> release branch strategy, then right before the
final push of the code into prod we merge the release branch with the master
branch to ensure there is no merge conflict. The merge to master does not
trigger any CICD, that is handled by our orchastration software. From the git
branches, commits to a feature branch build and deploy to a sandbox env.
Commits to a release branch trigger build and deploy to a dev environment,
then that build artifact is promoted up the environments up to and including
prod by our orchastration software.

------
mping
If the devs are experienced and you have confidence in tests, I like the trunk
based approach WITH pair programming. Pairing takes care of review, testing
ensures functionality and trunk based facilitates CD. If it is an internal
project it's even better because the cost of a bug tends to be lower than
public projects.

~~~
shoo
> If it is an internal project it's even better because the cost of a bug
> tends to be lower than public projects.

By this, do you mean that trunk-based development with pairing has a higher
rate of shipping defects to production than other approaches?

If so -- what's the upside of this approach?

~~~
mping
I mean if you are inexperienced the risk is lower.

------
wikibob
You want real continuous deployment?

Or just continuous delivery?

They are not the same thing.

If you want real continuous deployment (which you should):

\- you need feature flags. See something like LaunchDarkly.com

\- you need Trunk Based Development. This means no branches. Or rather, only
branches that live less than one business day.

See [https://trunkbaseddevelopment.com](https://trunkbaseddevelopment.com) And

[https://paulhammant.com/categories.html#Trunk-
Based_Developm...](https://paulhammant.com/categories.html#Trunk-
Based_Development) And

[https://www.branchbyabstraction.com/](https://www.branchbyabstraction.com/)

