Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Trunk-Based Development

trunkbaseddevelopment.com

Post reply on HN
Print view View original

101–108 of 108 posts

Re: Trunk-Based Development

#101

Post by giancarlostoro »

purerandomness wrote: post #65
giancarlostoro wrote: post #51

Earlier quoted context omitted.

They deleted every branch on merge, and had us rebase for merges. Before trunk based development was introduced, everyone on the team understood what the flow was. Afterwards, whichever developer was picked to cut a release, took half a day to figure it out to make sure they didn't screw up. I would have rather just used SVN and called it a day.

> They deleted every branch on merge 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…

> Wait, this doesn't sound like trunk-based development.

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.

Re: Trunk-Based Development

#102

Post by tnecniv »

dboreham wrote: post #23
Scubabear68 wrote: post #16

Earlier quoted context omitted.

I am amazed at how much “process” developers these days have to adhere to, including complicated branching strategies plus a whole lot more. So much time wasted doing busy work. I have always been happiest in a trunk-based dev model, but in many orgs it is heresy to even mention it.

Imho this is an emergent property from the fact that most folks don't understand what they're doing. If they did, then every time Mr Dilbert pointy head dude comes up with some nonsense process, they'd explain why it isn't beneficial. Instead most of the time everyone nods. Lawyers don't have crazy people telling them how to write contracts. Doctors don't have people telling them how to saw off legs. Teachers kind of…

Lawyers do. My dad is winding down his legal career but the bulk of it was spent writing corporate loan contracts. He’d constantly have clients asking him to make “small changes” to the document that either made no sense or were, in fact, large changes that would rob him of his weekend. While his specialty was niche, it was not so niche that appeasing the client for their future business was not important. His clients drove him crazy with this stuff but at least he could bill those hours.

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.

Re: Trunk-Based Development

#103

Post by Flux159 »

ramraj07 wrote: post #68
Flux159 wrote: post #7

I think that good tooling is a necessity to do trunk based development well - not just CI/CD and testing on PRs, but also being able to have stacks of commits in multiple PRs before landing as a whole (from ghstack, Sapling, or Graphite). 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 beyo…

Which of those three tools works best on GitHub? Ideally without paying (not that I mind paying but it’s impossible to get the approval for some niche tool like this)

I’ve used both Sapling cli & Graphite with github repos without having to pay anything.

They both have extensions for vscode as well that makes it easier to manage stacks.

Re: Trunk-Based Development

#104

Post by tomoyoirl »

striking wrote: post #33
tomoyoirl wrote: post #12

[flagged]

As of February 2016, references to "slave" in documentation began to be replaced with "agent": https://issues.jenkins.io/browse/JENKINS-27268 The comment I'd make is that this appears to have been settled nearly eight years ago in this particular context, and that maybe you should give it a rest.

You seem to misunderstand. My objections to the change are minimal. It is the incompleteness of the change that is remarkable.

Re: Trunk-Based Development

#105

Post by striking »

tomoyoirl wrote: post #104
striking wrote: post #33

Earlier quoted context omitted.

As of February 2016, references to "slave" in documentation began to be replaced with "agent": https://issues.jenkins.io/browse/JENKINS-27268 The comment I'd make is that this appears to have been settled nearly eight years ago in this particular context, and that maybe you should give it a rest.

You seem to misunderstand. My objections to the change are minimal. It is the incompleteness of the change that is remarkable.

I feel like I understand well enough, I feel you've misrepresented the magnitude of the issue.

Re: Trunk-Based Development

#106

Post by tomoyoirl »

striking wrote: post #105
tomoyoirl wrote: post #104

Earlier quoted context omitted.

You seem to misunderstand. My objections to the change are minimal. It is the incompleteness of the change that is remarkable.

I feel like I understand well enough, I feel you've misrepresented the magnitude of the issue.

[flagged]

Re: Trunk-Based Development

#107

Post by GauntletWizard »

purerandomness wrote: post #65
giancarlostoro wrote: post #51

Earlier quoted context omitted.

They deleted every branch on merge, and had us rebase for merges. Before trunk based development was introduced, everyone on the team understood what the flow was. Afterwards, whichever developer was picked to cut a release, took half a day to figure it out to make sure they didn't screw up. I would have rather just used SVN and called it a day.

> They deleted every branch on merge 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…

GitHub "deletes" branches on merge, but it doesn't truly delete them - rather, it removes the branch, that's deleted, but the commits comprising the "pull request" are saved and referenced from that pull, so they never go away. They're slightly harder to find in GitHub and may disappear from your local copy, though.

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.

Re: Trunk-Based Development

#108

Post by codethief »

andix wrote: post #80
codethief wrote: post #75

Earlier quoted context omitted.

> 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. 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 wi…

I think this kind of complexity is not the reality of most developers. They just stop all old services, update them and re-start them during a maintenance window.

That'd be news to me. At least in all big companies that I've come across, where revenue depends on services to be available 24/7 and maintenance windows maybe happen once a year, I have never heard of such a thing.
Post reply on HN