Comment by gouggoug

Comment by gouggoug 12 hours ago

19 replies

View on Hacker News

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 12 hours 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.

Reply View 7 replies
  • tankenmate 12 hours 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.

    Reply View 6 replies
    • jmmv 8 hours ago

      You can configure branch protections in GitHub to rebase during PR merges and enforce a linear history.

      Reply View 0 replies
    • brabel 9 hours 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!

      Reply View 4 replies
      • tankenmate 9 hours 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.

        Reply View 1 reply
        • brabel 4 hours ago

          Yes I know. That's not how they said they are doing it.

          Reply View 0 replies
      • jiggunjer 9 hours ago

        Sorry but you building wrong if you need separate builds.

        Reply View 1 reply
        • skydhash 6 hours 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.

          Reply View 0 replies
overfeed 4 hours 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.

Reply View 2 replies
  • gouggoug an hour 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.

    Reply View 0 replies
ezst 9 hours 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).

Reply View 4 replies
  • gouggoug 4 hours ago

    > There's nothing inherently wrong with having per-env branches

    There is when you stop thinking in terms of dev, staging and prod, and you realize that you might have thousands of different environments, all named differently.

    Do you create a branch for each one of them?

    Using the environment name as branch name is coupling your repository with the external infrastructure that's running your code. If that infrastructure changes, you need to change your repository. That in itself is a cue it's a bad idea to use branches this way.

    Another issue with this pattern is that you can't know what's deployed at any given time in prod. Deploying the "production" branch might yield a different result 10 minutes from now, than it did 25 minutes ago. (add to the mix caching issues, and you have a great recipe for confusing and hard to debug issues)

    If you use tags, which literally are meant for that, combined with semver (though not necessarily a requirement, but a strong recommendation), you decouple your code and the external environment.

    You can now point your "dev" environment to "main", point staging to ">= v1.25.0" and "prod" to "v1.25.0", "dev-alice" to "v2.0.0", "dev-john" to "deadb33f".

    When you deploy "v1.25.0" in prod, you _know_ it will deploy v1.25.0 and not commit deadb33f that so happened to have been merged to the "production" branch 30 seconds ago.

    Reply View 0 replies
  • zx8080 7 hours 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?

    Reply View 0 replies
  • skydhash 6 hours ago

    Branch is semantic. The true unit is commit and the tree is applying a set of commits. Branching is just selecting a set of commits for a tree. There’s no wrong or right branch, there is just the matter of generating the wrong patch

    Reply View 1 reply
    • gouggoug 3 hours ago

      Branches are mutable and regularly point to a new commit. Branching is selecting an active line of development, a set of commits that change over time.

      That's why git also offer tags. Tags are immutable.

      That's an important distinction.

      Reply View 0 replies
j1elo 4 hours 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.

Reply View 1 reply
  • gouggoug 4 hours 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

    Reply View 0 replies
kardianos 7 hours ago

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

Reply View 0 replies