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

61–70 of 72 posts

Re: Trunk Based Development

#61

Post by yjftsjthsd-h »

estimator7292 wrote: post #60

I still have nightmares from my first dev gig. We used SVN, which even in 2015 was prehistoric technology. The server was some awful rustbucket that couldn't sustain 100Mbit. Yes, it couldn't saturate basic 100megabit Ethernet. Everyone had to have big drives in their workstations to maintain multiple local trees. You just couldn't work otherwise. But probably the worst part was that when I started it was a loose org…

That sounds like trunk-based development with extra steps (and only a single release branch that gets wiped every 2 weeks).

Re: Trunk Based Development

#62

Post by StrangeSound »

estimator7292 wrote: post #60

I still have nightmares from my first dev gig. We used SVN, which even in 2015 was prehistoric technology. The server was some awful rustbucket that couldn't sustain 100Mbit. Yes, it couldn't saturate basic 100megabit Ethernet. Everyone had to have big drives in their workstations to maintain multiple local trees. You just couldn't work otherwise. But probably the worst part was that when I started it was a loose org…

Deleting the trunk every two weeks physically hurts to read.

I'm always surprised by how popular SVN still is though. I ported my old Sublime SVN plugin to VS Code years ago for fun, and I still get issues raised today (usually in Chinese, so it seems popular there). If you look at the VS Code marketplace, the top SVN extension has ~1.3m installs.

Bit of a tangent, but it probably wasn't a good idea to release an extension for something I had stopped using long before, particularly when you have to maintain it!

Re: Trunk Based Development

#63

Post by StrangeSound »

rsaarsoo wrote: post #29
aidos wrote: post #22

Earlier quoted context omitted.

It’s pretty hard to keep the commits in a working branch in a good legible state - certainly it takes work to do it. In 25 years of professional development I’ve never really had a situation where the commits on a branch would have helped me understand what was going on a year ago when the work was done. That includes pretty big bits of project work. I’d much rather have a trunk with commits at the granularity of fea…

I on the other hand have never come across a scenario where I run git bisect to find a commit that broke something, discover a small commit as a culprit and wish I had instead found a commit that's hundreds of lines long. What has happened a whole lot though is the exact opposite.

Our strategy is to squash on merge and ensure the JIRA ticket reference is in the MR title. You have the granularity of the feature which is going to help guide you on the intention. It's also much easier to enforce. People like to write and commit code in their own way.

Re: Trunk Based Development

#64

Post by bonesss »

estimator7292 wrote: post #60

I still have nightmares from my first dev gig. We used SVN, which even in 2015 was prehistoric technology. The server was some awful rustbucket that couldn't sustain 100Mbit. Yes, it couldn't saturate basic 100megabit Ethernet. Everyone had to have big drives in their workstations to maintain multiple local trees. You just couldn't work otherwise. But probably the worst part was that when I started it was a loose org…

I kinda love SVN, it was a leap up from many popular solutions at the time.

And some people hate it… but, up to and including this story of random-assed deletions, scratch the surface of why and all you hear are self-inflicted harm through bad process.

“Git sucks butt because at OUR shop we start a new repo every few weeks with copy n paste and don’t understand partial checkouts and under-resource the primary host server and also people sneak code into production for funsies.”… … yeah, sounds like “Git” has problems…

Re: Trunk Based Development

#65

Post by time4tea »

TBD - its pretty great... aligned also with continuous deployment:

It allows you to get feedback from customers very fast.

It allows you to improve the software very fast.

It allows you to react to the feedback you just got very fast.

Yes, its tricky! You need fast builds, that give you actionable feedback on whether you did a whoopsie.

Yes, it works for all sorts of things: regulated industries, incl finance, embedded systems, apps, websites, ...

Yes, you do need to rethink how changes happen, to look for ways to make that big change into multiple or even many smaller changes, this often has lots of unanticipated benefits.

Yes, it scales to very large deployments and quite large teams.

Re: Trunk Based Development

#66

Post by aidos »

locknitpicker wrote: post #58
aidos wrote: post #22

Earlier quoted context omitted.

It’s pretty hard to keep the commits in a working branch in a good legible state - certainly it takes work to do it. In 25 years of professional development I’ve never really had a situation where the commits on a branch would have helped me understand what was going on a year ago when the work was done. That includes pretty big bits of project work. I’d much rather have a trunk with commits at the granularity of fea…

> In 25 years of professional development I’ve never really had a situation where the commits on a branch would have helped me understand what was going on a year ago when the work was done. My professional experience contrasts with yours. I've even worked at a company where commit history and PRs were so central to understand and explain changes that PRs were even used as the authoritative sources on how to implemen…

Maybe a slight misinterpretation of what I meant. The commit that goes with a PR is definitely useful context, but I’ve found more granular than that is seldom useful. Even big ones like “move from angular to react” - the details of someone getting something wrong in there don’t matter, it’s the scale of it that just makes me go “oh yeah, this is bound to be a mistake”.

Maybe different in other places, but after 15 years in my codebase, I’m still happy with a simple linear history.

Re: Trunk Based Development

#67

Post by thr0w »

Who cares.

Prescribed workflows apply solutions from the wrong direction.

Determine what's impeding your organization, devise a solution.

The last guy I encountered who evangelized something like this had smart frames and a Lovecraft anthology prominently perched in the background of his Zoom shot.

Re: Trunk Based Development

#68

Post by csb6 »

F-W-M wrote: post #8
alfiedotwtf wrote: post #7

The thing missing with a lot of these branch management posts is release management… because it’s lovely to live in an ideal happy-path world, but what happens when main is tagged for release, only some customers update, main moves of with multiple breaking changes, and only then do some customers require fixes to their releases (who could all be on different i.e even older tags)? Do you take their tagged release, fi…

If you need to support multiple versions at the same time, you need to extend TBD in some way. We just cherry-picked stuff back to release branches, if we needed a fix.

Yeah, I work on avionics software where we sometimes need to support old releases with fixes for many years, and this is basically how we do it. Essentially maintaining multiple trunks and only backporting changes needed by customers using the old releases (there is a high bar so it has to be something like a security fix or an important bug fix)

Re: Trunk Based Development

#69

Post by aidos »

rsaarsoo wrote: post #29
aidos wrote: post #22

Earlier quoted context omitted.

It’s pretty hard to keep the commits in a working branch in a good legible state - certainly it takes work to do it. In 25 years of professional development I’ve never really had a situation where the commits on a branch would have helped me understand what was going on a year ago when the work was done. That includes pretty big bits of project work. I’d much rather have a trunk with commits at the granularity of fea…

I on the other hand have never come across a scenario where I run git bisect to find a commit that broke something, discover a small commit as a culprit and wish I had instead found a commit that's hundreds of lines long. What has happened a whole lot though is the exact opposite.

For me, all the code in the PR at that point is in question. The code was changed as part of a bigger part of work and reverting it without understanding why might cause issues back the other way.

The other thing to say - that is missing from this conversation - is that if you’re using github, the original commits are still against the PR.

Re: Trunk Based Development

#70

Post by mcv »

dxdm wrote: post #4
jascha_eng wrote: post #2

I've rarely seen the first description of it where people actually commit directly to main. Except in very early stage projects. But it does always feel the fastest if you only review code "on-demand" in PRs/MRs instead of enforcing it for every change. I think in a team with good ownership, enforcing formal reviews slows down a lot. But of course in a larger code base where no single engineer can understand all the…

As I understand it, trunk based development does not call for committing directly to main. It says to avoid long-lived branches for releases, whole features, etc. There's nothing wrong with small, short-lived branches that can be quickly reviewed and merged into main. That being said, I've been in a small team where the blessed style was to commit directly to main and do reviews "on demand". It quickly gets features…

What counts as "long-lived"? Our shortest lived branches are quick fixes because something got merged into main that doesn't work properly.

I'd like main to always be ready for production, but that seems an elusive goal no matter what git workflow you use.

The best way to prevent complex merges does not depend on your git strategy, but on how modular you make your code. If a change requires changes to only a single file, and your files aren't too big, there's little chance of conflict. The more files need to be changed (often because the same thing needs to be declared in 4 different places), the bigger the chance of conflict. Same with larger files. Each file should have a single concern.

Post reply on HN