Hacker News Reader

Comment by Uvix | Hacker News Reader

Production shouldn't have its own branch - it shouldn't even be a new build at all. The same binaries that were deployed to staging should be redeployed to production once you approved. Otherwise, your "staging" environment has the wrong name... and the testing there doesn't represent what goes to production.

View on HN

In a system with production branches and staging, you build for staging from the production branch.

When you're in the release process, the branch won't match what's currently deployed, but that's ok. The point of a production branch is not to indicate what is on production at this instant, but to be a record of what was deployed to production or at least was intended to be, for changes that get canceled before deployment.

Building for staging from the production branch would be fine. Grandparent explicitly said they build for staging from the dev branch, though.

Oh yeah. I missed that. Sounds like they use their staging for dev work too then. Which is like ok, but confusing.

Why not? A branch is a pointer to a commit, so the commit built for staging can be the same binary that will be deployed to production, if the production branch is updated to point to the same commit as staging was pointing to. No rebuild necessary because it is the same commit.

If you have fully reproducible builds, and if it's from the same commit, then it's probably okay. With multiple branches in play, and staging built from a different branch than production, the latter doesn't hold.

Good point. That is my conclusion as well, its been a while since I worked on deployments, but that is how we set up. Deploying is just a different pipeline on main branch that runs same exact artifact build in production

Reply on news.ycombinator.com