karmakaze 24 days ago [-]
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 25 days ago [-]
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 25 days ago [-]
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 24 days ago [-]
> 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 18 days ago [-]
I mean if you are inexperienced the risk is lower.
wikibob 24 days ago [-]
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/