6 ms·

Somewhat related... At [company x] someone wrote a starter guide that tells developers to create a "production", "staging" and "dev" branch for any new repo. W

Somewhat related... At [company x] someone wrote a starter guide that tells developers to create a "production", "staging" and "dev" branch for any new repo. We have tons of repositories that follow this pattern. For many of them, each branch has taken of its own life and could be considered its own completely different codebase. It's a nightmare to manage and it confuses developers on a regular basis. Don't do this. If you want to deploy different versions of your software in different environments, use SEMVER and git tags. Don't create 1 branch per environment... I have since edited that starter guide and crossed out this recommendation.

jiggunjer 1y ago
It works fine if you review PRs and only allow STG->PRD promotions. It breaks down when people start making separate builds for each env. Treat env as config as you'll just have to manage a config folder in that repo.
- tankenmate 1y ago
  I concur, it works fine as long as devs follow the procedure. I also prefer to enforce linear history as well so that git bisect works properly; but then this requires devs to understand how to use --ff-only and also if you're using github to use a github action to fast forward as github doesn't natively support fast forward (one of github's many sins). But then I also find I need to train devs on how git actually works and how to use git properly because I find that only about 10% of devs actually understand git. But it works out best for everyone once all the devs understand git, so generally most devs appreciate it when someone is willing to teach them the ins and outs (but not all devs appreciate it before they learn it properly though). As always though, it's trade offs.
  - brabel 1y ago
    Sorry but you are just using source control very wrong if you keep 2 parallel environments in the exact same code base but different branches. The build itself should know whether to build for one environment or another!
    - jiggunjer 1y ago
      Sorry but you building wrong if you need separate builds.
      - skydhash 1y ago
        Mobile apps release process will disagree with you. there’s a gap of around 4 days between what you consider as a release and what can be on prod. If you got rebutted by review, you need to edit the code. If you want to rollback, you need to edit the code. You can only be linear if you control releases.
    - tankenmate 1y ago
      They are the same only sometimes; devs work on code on feature / fix / whatever branch, then when they've finished dev testing you do a code review and then it gets fast forwarded onto the dev branch, then when it suits for staging (non dev team stakeholder testing / infra testing) it gets fast forwarded to staging, then when it passes staging testing (if necessary), then it get ff onto prod and deployed. so dev will sometimes point to the same commit as staging but sometimes not, and staging will point to the same commit as prod but sometimes not. It's a funnel, a conveyor belt if you will.
      - brabel 1y ago
        Yes I know. That's not how they said they are doing it.
  - jmmv 1y ago
    You can configure branch protections in GitHub to rebase during PR merges and enforce a linear history.
ezst 1y ago
> For many of them, each branch has taken of its own life and could be considered its own completely different codebase. Seems you have bigger process issues to tackle. There's nothing inherently wrong with having per-env branches (if one thing, it's made harder by git being so terrible at branching in the general/long lived case, but the VCS cannot alone be blamed for developers consistently pushing to inadequate branches).
- zx8080 1y ago
  > if one thing, it's made harder by git being so terrible at branching in the general/long lived case Interesting. What's wrong with branching in git?
  - ezst 1y ago
    Before git abused the terminology, a branch used to refer to a long-lived/persistent commit lineage, most often implemented as a commit-level flag/attribute, OTOH, git branches are pointers to one single commit (with the git UI tentatively converting this information sometimes into "that commit, specifically" or sometimes as "all ancestors commits leading to that commit", with more or less success and consistency). Where it matters (besides fostering good/consistent UX) is when you merge several (topological) branches together: git won't be able to tell if you just merged A into B or B into A. Although the content is identical at code-level, the semantic/intent of the merge is lost. Similarly, once the head has progressed so much ahead and your history is riddled with merges, you can't tell from the DAG where the individual features/PR/series start and end. This makes bisecting very hard: while hunting down a regression, you would rather avoid checking-out mid-series commits that might break the build, and instead stick to the series boundaries. You can't do that natively with git. That also makes maintaining concurrent versions unnecessarily difficult, and many projects are struggling with that: have you seen for instance Django¹ prefixing each and every commit with the (long-lived) branch name? That's what you get with git while most other VCSes (like Mercurial, my preference) got right from the start. ¹: https://github.com/django/django/commits/stable/6.0.x https://github.com/django/django/commits/stable/6.0.x
- skydhash 1y ago
kardianos 1y ago
Generally agree. All changes for me are cherry-picked to master only.
j1elo 1y ago
"At company x, they had a kitchen and a couple meeting rooms. Devs started using the rooms for cooking, and the kitchen for team standups." Tools are just there, it's people who misuse them. If devs at company x are incapable of understanding that you shouldn't be cooking an omelette in the meeting room, to be honest that's on the dev, not on the separation of concerns that was put there for them. Probably what's missing there is training to set the expectations, policing on their actions, and a soft reprimand when the typical first time mistake is done. But if the metaphorical rooms have no indicators, no name tags, and no obvious usage guidelines, because no one bothered to set them up, then yeah expect board meetings to end up happening in the kitchen.
- gouggoug 1y ago
  > Tools are just there, it's people who misuse them. Absolutely. And it doesn't help when people write guides actively encouraging mis-using tools
overfeed 1y ago
> Don't do this There are multiple valid branching strategies. Your recommended strategy works well[0] with evergreen deployments, but would fail hard if you intend to support multiple release versions of an app, which happens often in the embedded world with multiple hardware targets, or self-hosted, large enterprise apps that require qualification sign-offs. 0. Semver uas many issues that I won't repeat here, mostly stemming from projecting a graph of changes onto a single-dimension.
- deepsun 1y ago
  I always thought multiple hardware targets are solved by build flags. And keep the one branch. E.g. in Go you can include/exclude a file based on "build tags": https://www.digitalocean.com/community/tutorials/customizing-go-binaries-with-build-tags https://www.digitalocean.com/community/tutorials/customizing...
- gouggoug 1y ago
  > but would fail hard if you intend to support multiple release versions of an app, which happens often in the embedded world with multiple hardware targets, or self-hosted, large enterprise apps that require qualification sign-offs. I don't have experience in this world, indeed. But isn't "multiple release versions of an app" just "one application, with multiple different configurations"? The application code is the same (same version), the configuration (which is external to the application) is different. Your build system takes your application code and the configuration as input, and outputs artifacts for that specific combination of inputs.
  - overfeed 1y ago
    > But isn't "multiple release versions of an app" just "one application, with multiple different configurations"? That would be nice (and evergreen), but that's not always the case. It's common to have different versions of the app released simultaneously, with different features and bugfixes shipped. Think of Microsoft simultaneously supporting Windows 10 and 11, while still releasing patches for XP: they are all individual OSes that share some common code, but can't be detangled at build times[1] The customer will be reluctant to upgrade major versions due to licensing costs and risk if breakage (your code, or their integrations), but still expect bugfixes (and only bugfixes) on their deployed versions, which you're contracted to provide. Using the evergreen approach. I'm not convinced using build flags to manage which code is shipped is superior to release branches, I fall on the side of release branches because using bisect is invaluable. 1. I suppose as long as the build system is turing complete, one could hypothetically build Windows XP, 7, 8, 10 and 11 off the same codebase using flags. I would not envy that person.

jiggunjer 1y ago

It works fine if you review PRs and only allow STG->PRD promotions. It breaks down when people start making separate builds for each env. Treat env as config as you'll just have to manage a config folder in that repo.

tankenmate 1y ago
I concur, it works fine as long as devs follow the procedure. I also prefer to enforce linear history as well so that git bisect works properly; but then this requires devs to understand how to use --ff-only and also if you're using github to use a github action to fast forward as github doesn't natively support fast forward (one of github's many sins). But then I also find I need to train devs on how git actually works and how to use git properly because I find that only about 10% of devs actually understand git. But it works out best for everyone once all the devs understand git, so generally most devs appreciate it when someone is willing to teach them the ins and outs (but not all devs appreciate it before they learn it properly though). As always though, it's trade offs.
- brabel 1y ago
  Sorry but you are just using source control very wrong if you keep 2 parallel environments in the exact same code base but different branches. The build itself should know whether to build for one environment or another!
  - jiggunjer 1y ago
    Sorry but you building wrong if you need separate builds.
    - skydhash 1y ago
      Mobile apps release process will disagree with you. there’s a gap of around 4 days between what you consider as a release and what can be on prod. If you got rebutted by review, you need to edit the code. If you want to rollback, you need to edit the code. You can only be linear if you control releases.
  - tankenmate 1y ago
    They are the same only sometimes; devs work on code on feature / fix / whatever branch, then when they've finished dev testing you do a code review and then it gets fast forwarded onto the dev branch, then when it suits for staging (non dev team stakeholder testing / infra testing) it gets fast forwarded to staging, then when it passes staging testing (if necessary), then it get ff onto prod and deployed. so dev will sometimes point to the same commit as staging but sometimes not, and staging will point to the same commit as prod but sometimes not. It's a funnel, a conveyor belt if you will.
    - brabel 1y ago
      Yes I know. That's not how they said they are doing it.
- jmmv 1y ago
  You can configure branch protections in GitHub to rebase during PR merges and enforce a linear history.

ezst 1y ago

> For many of them, each branch has taken of its own life and could be considered its own completely different codebase. Seems you have bigger process issues to tackle. There's nothing inherently wrong with having per-env branches (if one thing, it's made harder by git being so terrible at branching in the general/long lived case, but the VCS cannot alone be blamed for developers consistently pushing to inadequate branches).

zx8080 1y ago
> if one thing, it's made harder by git being so terrible at branching in the general/long lived case Interesting. What's wrong with branching in git?
- ezst 1y ago
  Before git abused the terminology, a branch used to refer to a long-lived/persistent commit lineage, most often implemented as a commit-level flag/attribute, OTOH, git branches are pointers to one single commit (with the git UI tentatively converting this information sometimes into "that commit, specifically" or sometimes as "all ancestors commits leading to that commit", with more or less success and consistency). Where it matters (besides fostering good/consistent UX) is when you merge several (topological) branches together: git won't be able to tell if you just merged A into B or B into A. Although the content is identical at code-level, the semantic/intent of the merge is lost. Similarly, once the head has progressed so much ahead and your history is riddled with merges, you can't tell from the DAG where the individual features/PR/series start and end. This makes bisecting very hard: while hunting down a regression, you would rather avoid checking-out mid-series commits that might break the build, and instead stick to the series boundaries. You can't do that natively with git. That also makes maintaining concurrent versions unnecessarily difficult, and many projects are struggling with that: have you seen for instance Django¹ prefixing each and every commit with the (long-lived) branch name? That's what you get with git while most other VCSes (like Mercurial, my preference) got right from the start. ¹: https://github.com/django/django/commits/stable/6.0.x https://github.com/django/django/commits/stable/6.0.x
skydhash 1y ago

kardianos 1y ago

Generally agree. All changes for me are cherry-picked to master only.

j1elo 1y ago

"At company x, they had a kitchen and a couple meeting rooms. Devs started using the rooms for cooking, and the kitchen for team standups." Tools are just there, it's people who misuse them. If devs at company x are incapable of understanding that you shouldn't be cooking an omelette in the meeting room, to be honest that's on the dev, not on the separation of concerns that was put there for them. Probably what's missing there is training to set the expectations, policing on their actions, and a soft reprimand when the typical first time mistake is done. But if the metaphorical rooms have no indicators, no name tags, and no obvious usage guidelines, because no one bothered to set them up, then yeah expect board meetings to end up happening in the kitchen.

gouggoug 1y ago
> Tools are just there, it's people who misuse them. Absolutely. And it doesn't help when people write guides actively encouraging mis-using tools

overfeed 1y ago

> Don't do this There are multiple valid branching strategies. Your recommended strategy works well[0] with evergreen deployments, but would fail hard if you intend to support multiple release versions of an app, which happens often in the embedded world with multiple hardware targets, or self-hosted, large enterprise apps that require qualification sign-offs. 0. Semver uas many issues that I won't repeat here, mostly stemming from projecting a graph of changes onto a single-dimension.

deepsun 1y ago
I always thought multiple hardware targets are solved by build flags. And keep the one branch. E.g. in Go you can include/exclude a file based on "build tags": https://www.digitalocean.com/community/tutorials/customizing-go-binaries-with-build-tags https://www.digitalocean.com/community/tutorials/customizing...
gouggoug 1y ago
> but would fail hard if you intend to support multiple release versions of an app, which happens often in the embedded world with multiple hardware targets, or self-hosted, large enterprise apps that require qualification sign-offs. I don't have experience in this world, indeed. But isn't "multiple release versions of an app" just "one application, with multiple different configurations"? The application code is the same (same version), the configuration (which is external to the application) is different. Your build system takes your application code and the configuration as input, and outputs artifacts for that specific combination of inputs.
- overfeed 1y ago
  > But isn't "multiple release versions of an app" just "one application, with multiple different configurations"? That would be nice (and evergreen), but that's not always the case. It's common to have different versions of the app released simultaneously, with different features and bugfixes shipped. Think of Microsoft simultaneously supporting Windows 10 and 11, while still releasing patches for XP: they are all individual OSes that share some common code, but can't be detangled at build times[1] The customer will be reluctant to upgrade major versions due to licensing costs and risk if breakage (your code, or their integrations), but still expect bugfixes (and only bugfixes) on their deployed versions, which you're contracted to provide. Using the evergreen approach. I'm not convinced using build flags to manage which code is shipped is superior to release branches, I fall on the side of release branches because using bisect is invaluable. 1. I suppose as long as the build system is turing complete, one could hypothetically build Windows XP, 7, 8, 10 and 11 off the same codebase using flags. I would not envy that person.