Hacker News Reader

Comment by redcobra762 | Hacker News Reader

Wait so no develop branch? The utility gained by having “what’s in production” and “what we’re working on” as separated feels hard to part with.

View on HN

Your local repo is the equivalent of the development branch. Yes, that means you don't collaborate with others on development branches, or go for weeks committing only to a branch.

If you save up a bunch of work, dump it on the main branch, then start a new development branch that lets you escape from the integration pain of your big merge, then trunk becomes a dumping ground that nobody wants to (or can) work on.

Seems strange. Sometimes we’ll have feature branches that are made up of different parts, with different devs collaborating to build those parts out. For this I don’t see a way around having some staging branch with two devs sending PRs to before you work out all kinks and merge the staging branch back into main

This is the hardest part about trunk based development - changing your way of thinking. Everything needs to be decomposed into much smaller changes, and you need to think about the impact of each of them being deployed into production (since that will happen). New features should exist behind some kind of feature gating or dial-up capability, or a new API version with restricted access, etc.

That seems painful but it's less painful than merge hell or deploying a change with a massive delta to production and needing to roll it back and unpick what went wrong.

I dunno if I’m fully onboard, but anything that forces devs to think in terms of smaller changes will always get my attention.

"before you work out all kinks and merge the staging branch back into main"

Working out all kinks on an isolated branch is very hard to do. You need to integrate to hear the screams of the team you never expected your change would affect. So your choice is to integrate commit by commit on trunk, or to wad it all up into a single waterfall release from your branch to trunk, and then spend hours/days bisecting to find which commit caused the screams.

As jozzas said, feature flags enable your code to safely lurk on trunk before it's functional.

Have the devs integrate in their own branch(es).

if that's the only reason for the branch, you can just as easily determine which commit is on which environment with tags

Or put the sha in the version number.

So if the “deployed branch” were really just a “tag”, that would fit trunk based development? Because that’s basically what git is doing. It’s not like there are two sets of files anywhere, afaik.

My understanding of this though is that there isn’t supposed to be a difference between “what we’re working on” and “what’s deployed”, which I think then means you don’t really do “long term” development.

I've been working on my product for over 8 years, sometimes alone, sometimes with a tiny team.

I have a mono-repo with one master branch - that auto-deploys to test - and one release branch that auto-deploys to staging. I can hot-swap my staging and production environment with the click of a button.

Simple, and it allows us to deploy a hotfix of needed, and we've done some major work on master that needs to be validated first...

But,... It all depends on your context and your needs...

the hotfix is extremely useful

but you have to be so so careful when you're missing up history, when it comes to db migrations and api compatibility

Sounds neat, but I still think complexity is removed if the deployment is not directly linked to the code repository. For me the code repositories purpose is to build software, and operation is not it's responsibility.

I prefer having a gitops repository that describes the environment. Completely decoupled from the source code repository. If some automation directly from the source repository is required, a CI job can automatically update the gitops repository and trigger a deployment.

Separation of concerns.

It’s still trunk based development even if a feature branch / tag is created that will match production.

I'm convinced that development and operation (deployment) should be thought of separately. The branching model for the code should only serve the purpose to create a working product (artifacts of some kind). Those artifacts should be versioned (can be semver, or just the short hash of the commit, or anything else).

Once something is ready for deployment it can be deployed, in the best case this is just clicking one button or one CLI command.

Developers shouldn't be afraid that one wrong commit can automatically just go to production.

If there are multiple environments it quickly gets impossible to keep track of "what's in production" as a branch.

Two possible solutions: Git tag everything that's getting deployed. Or just keep track of the commit hash that is deployed.

I think the idea is that, rather than storing two versions of the code in your version control system, you store both versions in trunk and gate with a feature flag.

Reply on news.ycombinator.com