Trunk-Based Development(trunkbaseddevelopment.com) |
Trunk-Based Development(trunkbaseddevelopment.com) |
The projects at my company that use the complicated actions with gitflow are slower and less efficient.
When I release a service at my company I just do trunk based ,but I have to redo the GitHub actions initially to save it from itself. Over the long run it saves me a lot of time.
Same if I say "I'm not doing TDD, because I think it's bad". I've seen so many people claiming to do TDD, but none of them ever actually did.
Trunk-based development also doesn't mean that you are not allowed to create branches.
And you can still check out an older version.
And if QA finds something, there's nothing preventing testing another release to figure out where the issue is. Git bisect is useful there too.
There are plenty of issues with git, but trunk development isn't really one of them.
This guide advises you to consider trunk based development if your release cycles are less than ~4 weeks. I'd suggest doing it no matter what. The only place where I've run into problems with this was managing very long term hold outs where we wanted to avoid changing user visible behavior. Instead of branches, we maintained literal copies of all the files for multiple years. I don't think revision control is the right place to solve that problem though, because there were no clear service boundaries to decide what things to pin, we just did it in an adhoc way.
Having worked at Facebook before where managing stacks of diffs was far better than GitHub, I wish that more of the improvements to the developer workflow could be open sourced beyond Sapling now that Phabricator is no longer supported.
They both have extensions for vscode as well that makes it easier to manage stacks.
It has its limitations, but for the the 90+% of places that aren't operating at Facebook scale, it's probably the right choice. It doesn't eliminate merge hell, but it does localize it, making it a lot easier to resolve conflicts without accidentally undoing somebody else's work.
It's especially well-suited for any projects that are in constant-iteration mode, where there's a steady stream of bugfixes and new developments getting deployed daily (or even multiple times a day).
You can even manage longer-lived branches after a fashion: the cleanest pattern seems to be to capture your changes into a patch, revert your branch to the commit immediately before your changes, merge/rebase main, then apply your patch on top. This is bad and lame because it rewrites history and requires a force push to get it into the remote, but it's also nice because it keeps your changes at the tip of the branch and makes review a bit easier in e.g. GitLab.
Every small shop I've worked with that has tried to use more complex branching models eventually hoses the repo and ends up burning a lot of dev hours one day trying to make sense of a git log that looks like a diagram of network sorting.
That said, trunk-based is probably not great if you actually do need to support multiple versions of a piece of software simultaneously.
For a short while it may work to just merge bugfixes to older versions. But after a while the changes to older versions need to be done independently. Implementing a fix for three versions will just take three times longer than for one version very soon.
A significant amount of Git-isms are based around Linux kernel needs. Which is great. But closed source and typical open source needs are pretty different, and much simpler.
Some recent discussion: https://news.ycombinator.com/item?id=34733805
Overall, this site reads like someone who's so convinced they're right that they don't bother to take other viewpoints seriously enough to actually refute them.
https://trunkbaseddevelopment.com/#scaled-trunk-based-develo...
Trunk does not prohibit feature branches or code review.
When you need to make a breaking change to one that is depended on by a lot of the other repos, it can be incredibly tedious to fix all the downstream effects.
Using trunk would resolve it, but would also of course introduce other issues.
When splitting up a product into multiple repositories a lot of new problems are created. Every sub-project needs to be testable completely independently and then in a later stage integrated with the other components and tested again.
With multi-repository it's much harder to isolate a change over multiple components into one PR and test those changes together. Instead they develop separately and after some time many of those changes are tested together. It's just making the feedback loop longer without any added value.
While I'm a fan of monorepos, that issue doesn't completely disappear there, does it? I mean, if the monorepo contains the code for N artifacts (say, N, microservices that interact with one another), you will still have to make sure that the master version of microservice 1 plays nicely with the currently deployed version of microservice 2.
How do things that have LTS versions in parallel with "regular" versions organize?
I'm convinced that complex branching strategies never magically solve any issues. They just confuse many people until every successful release feels like dark magic.
I genuinely did not know that. I thought working on individual branches, merging to master, and then cutting the release branch from there (to merge back into master if any changes were found during testing) was the only major way people actually did things.
I've worked on teams using trunk based development before and I ended up being the one having to fix other people's messes, deal with them losing work, and the absolute hell of trying to find where a bug was introduced.
The only people I really want on my team are those that understand Git. And even when there are team members that don't understand Git, I sure do and can pretty easily un-eff any situation someone gets themselves into.
Seriously, Git is actually simple and it should be a fundamental CS class taught at all universities.
The fact that is ever possible is a damning indictment on Git
> Git is actually simple
The clearest evidence that something isn’t simple is when there are thousands of people yelling in frustration that it’s simple.
Things that are actually simple don’t require a never ending stream of guides and tutorials.
The world can do much, much better than Git.
What does this have to do with a trunk based branching strategy?
> Seriously, Git is actually simple and it should be a fundamental CS class taught at all universities.
I'm fairly confused by this, as it doesn't seem to contradict OP, which is about using git...
So people don't merge branches to main branch, but tag releases from it. ok. But they still need to merge their changes to main first, right?
Same fucking thing, wrapped in execucrap.
I have always been happiest in a trunk-based dev model, but in many orgs it is heresy to even mention it.
Was the guy just totally full of it? Because honestly I wouldn't touch any "strategy" with a 10 foot pole that discourages pre-merge reviews.
I have known and worked with Steve Smith (the only "friends" mentioned in the website [0] - hi Steve! :D ) for years and we had many discussions about the merits of short-lived branches for peer review. Myself and a few others have argued that you can have pretty much all the benefits they were looking for with TBD without the draconian "always push to trunk" rule. It just takes a bit of discipline and communication, but to be honest I think the draconian one needs even more of those if it is to succeed.
I'm happy that the website has been updated since (it's been at least a few months, maybe even a couple years) to acknowledge and "allow" that strategy.
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.
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 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...
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.
Two possible solutions: Git tag everything that's getting deployed. Or just keep track of the commit hash that is deployed.
My VCS rule is that commit ids are sacrosanct. If you make a commit that commit is safe. You can do whatever the hell you want. Merge, rebase, whatever. But you can always go back to that commit.
This is kinda sorta true for Git. But that isn’t a first principle. And Git’s management of branch labels is super finicky.
Mercurials anonymous branching is a better default imho.
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.
but you have to be so so careful when you're missing up history, when it comes to db migrations and api compatibility
I know less about doctors, but they certainly have people that think they know better and question their course of treatment. Just look at the pandemic and vaccine nonsense. Doctors benefit from supply and demand (artificial or otherwise) meaning that they’re basically always booked up.
Developers have neither of those privileges unless you’re an in demand consultant.
But sure, if supporting an older release is some kind of ongoing trunk-based process this is also a viable solution.
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.
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.
I would have rather just used SVN and called it a day.
Wait, this doesn't sound like trunk-based development.
This sounds like a traditional branch-based workflow.
> to cut a release, took half a day to figure it out to make sure they didn't screw up.
Do you remember what was making the process complicated?
In trunk-based development, you ideally can tag a release wherever you're at. Your trunk is always stable and releasable. If it's not, you fix it and then release.
There's a lot of other moving parts to trunk-based, they can only be taught by experience. I've written the tutorial where I have people make mistakes, and then fix them, but the problem is that they make mistakes in making mistakes.
I'm not sure, I just know my employer had a third party managing releases for a while, then the guy who pitched Trunk based dev left, and we were left with people trying to follow the breadcrumbs.