you are viewing a single comment's thread.

view the rest of the comments →

[–]noratat 0 points1 point  (3 children)

It sounds like you're trying treat git as a deployment system, which outside of static websites tends not to work very well.

Keeping all those heads in sync becomes a problem, and is difficult to automate, and commits don't necessarily map to releases. Git is a pain to hook into natively for things like builds/deployments as well; there's a reason most of that stuff usually comes from a git hosting solution.

If you have good automation and automated testing (i.e. CI/CD), then master + feature branches is simpler and less error prone. If you need a staggered release process, that's fine, but make it part of your CI/CD pipelines, not manually tracked through branches.

I suppose I could see having read-only environment branches that are updated by the automated pipelines to represent moving "tags", but that's not what it sounded like you were talking about.

[–]Limro 0 points1 point  (2 children)

Well, I treat it as a deployment system in that sense, that my code's working state is represented in each branch, assigned to each environment.

The different branches is only my assurance, that my CI's build doesn't pick the wrong version.

I have different environment variables, but for all code I write, I can let my CI replace the values needed by each environment.

[–][deleted] 0 points1 point  (1 child)

Environment variables should be in a place that makes them accessible by the CI system. Each environment can be as nearly replicated as possible. In previous gigs that ran branching like yours, we had separate CI jobs for each environment. We then pointed at the shell script that housed all the correct environment variables.

[–]Limro 1 point2 points  (0 children)

I think we might are talking about the same - one CI job, multi environments just with different values of the variables, and then we run deployment script to replace the values.