Ask HN: Best branching strategies for continuous delivery? | Hacker News Reader

Ask HN: Best branching strategies for continuous delivery?

5 pointsljoshua6 comments

We're starting up a greenfield project delivering a web-based product meant for rapid iteration. We're using Git, and our team of about 5-6 devs all have had experience with different branching strategies in the past.

When aiming for a really smooth and testable CI/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?

We don'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's thoughts and war stories!

View on HN

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.)

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.

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.

> 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?

I mean if you are inexperienced the risk is lower.

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 And

https://paulhammant.com/categories.html#Trunk-Based_Developm... And

https://www.branchbyabstraction.com/

Reply on news.ycombinator.com