3 ms·

Every time I see some type of branching strategy it's always about main/master. Don't people have multiple environments, such as dev, test, pre-prod, prod? Thes

Every time I see some type of branching strategy it's always about main/master. Don't people have multiple environments, such as dev, test, pre-prod, prod? These strategies always apply merge/pull requests or changes directly to master. I protect every remote branch and require merge/pull requests to start on dev (unless of a hotfix.)

wodenokoto 5y ago
git flow, arguably the only branching strategy people talk about by name, is all about maintaining multiple environments [1] test environment is where PRs are deployed (or just tested) before being merged pre-prod is for the release branch and prod is for the master branch [1] https://nvie.com/posts/a-successful-git-branching-model/ https://nvie.com/posts/a-successful-git-branching-model/
- chrisweekly 5y ago
  Git Flow is not the only game in town! Take a look at GitLab Flow (and its variants), this intro does a good job of comparing related options (including git flow) -- https://docs.gitlab.com/ee/topics/gitlab_flow.html https://docs.gitlab.com/ee/topics/gitlab_flow.html
ramraj07 5y ago
My thinking is that you have one or more dev environments and the engineers are free to deploy whatever branch they want to these places whenever. If you have manual qa or some other team doing pre release qa, then merging your change to main can deploy to a stage env, and once the qa team okays it, the release propagates to prod. The stage env is thus optional.
- jcon321 5y ago
  But are you using a different branch for stage evn. As in, I wouldn't want to merge a release into master that gets deployed to a stage env. Because, if a critical hotfix is needed on master (for prod env) then I can't deploy prod again because master now has a new release in it (because of the stage env.)
  - ramchip 5y ago
    Master doesn't have to be the only branch that deploys to prod, you could create a hotfix branch (starting from an earlier commit) and set it to push to prod in your CI to get an emergency release out.
ramchip 5y ago
I generally setup CI to build from master and push to the test environment, then I manually promote the same artifact to prod when ready. This way there's no big "merge dev to prod" PRs, and the binary that runs in prod is 100% the same one tested in pre-prod.
nahname 5y ago
Environments are generally handled via deployment configuration.
ryan_lane 5y ago
Maintaining a branch for every environment is extremely complex and error prone. All the branching strategies you see are always about main because it's simpler. Ensure the code merged into the main branch is always in a working state and you don't need to have a complex branching strategy. This requires stricter testing practices in the PRs, and usually also involves either requiring PRs to be up to date with master prior to merge, or re-testing of master after merge, prior to the SHA being deployable.

wodenokoto 5y ago

git flow, arguably the only branching strategy people talk about by name, is all about maintaining multiple environments [1] test environment is where PRs are deployed (or just tested) before being merged pre-prod is for the release branch and prod is for the master branch [1] https://nvie.com/posts/a-successful-git-branching-model/ https://nvie.com/posts/a-successful-git-branching-model/

chrisweekly 5y ago
Git Flow is not the only game in town! Take a look at GitLab Flow (and its variants), this intro does a good job of comparing related options (including git flow) -- https://docs.gitlab.com/ee/topics/gitlab_flow.html https://docs.gitlab.com/ee/topics/gitlab_flow.html

ramraj07 5y ago

My thinking is that you have one or more dev environments and the engineers are free to deploy whatever branch they want to these places whenever. If you have manual qa or some other team doing pre release qa, then merging your change to main can deploy to a stage env, and once the qa team okays it, the release propagates to prod. The stage env is thus optional.

jcon321 5y ago
But are you using a different branch for stage evn. As in, I wouldn't want to merge a release into master that gets deployed to a stage env. Because, if a critical hotfix is needed on master (for prod env) then I can't deploy prod again because master now has a new release in it (because of the stage env.)
- ramchip 5y ago
  Master doesn't have to be the only branch that deploys to prod, you could create a hotfix branch (starting from an earlier commit) and set it to push to prod in your CI to get an emergency release out.

ramchip 5y ago

I generally setup CI to build from master and push to the test environment, then I manually promote the same artifact to prod when ready. This way there's no big "merge dev to prod" PRs, and the binary that runs in prod is 100% the same one tested in pre-prod.

nahname 5y ago

Environments are generally handled via deployment configuration.

ryan_lane 5y ago

Maintaining a branch for every environment is extremely complex and error prone. All the branching strategies you see are always about main because it's simpler. Ensure the code merged into the main branch is always in a working state and you don't need to have a complex branching strategy. This requires stricter testing practices in the PRs, and usually also involves either requiring PRs to be up to date with master prior to merge, or re-testing of master after merge, prior to the SHA being deployable.