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

171–180 of 210 posts

Re: Trunk-Based Development

#171

Post by viraptor »

alkonaut wrote: post #168
viraptor wrote: post #154

Earlier quoted context omitted.

It's not satire. In your case the automated tests are just weak. You call the trunk unstable, because you need extra manual testing. What the page describes is an improvement on that. The CI system should have good enough tests to guarantee your trunk is never considered unstable. Then it doesn't really matter when you make a release - it's not a big deal. (Just choose a commit you like)

I think "pick a commit" only holds up for server based software. For things like large desktop software with long term supported file formats, mission critical software where people might get killed if something malfunctions etc then it's pretty normal to have manual testing. If the cost of deployment of a release is high (N people training, downloading, installing) then you want few releases - and you can also motiv…

You're right. But I don't really expect anyone writing safety critical software to get their idea for the process straight off a blog. In that case you'd be going from requirements to how you achieve that. You also don't need continuous delivery. Basically a different world.

Re: Trunk-Based Development

#172

Post by paul_h »

paulddraper wrote: post #158
qwer wrote: post #137

Earlier quoted context omitted.

Anything involving long-lived feature branches especially ones with multiple collaborators, eg git-flow.

If I understand git-flow correctly, it's a trunk (develop) with a release branch (master).

We wrote about that: https://trunkbaseddevelopment.com/alternative-branching-mode...

Re: Trunk-Based Development

#173

Post by kosma »

stcredzero wrote: post #144
kosma wrote: post #68

This workflow, like all others, is just a formalization of some reality. The reality is that many organizations and teams run on nothing but trunk - and it more-or-less works on them. Some teams work by building blocks separately and then joining them together; other prefer to hammer away on a problem all together. Both approaches work. What worries me are emotional claims that the other approach is fundamentally fla…

Trunk-only is a reality. Not a reality some of us would want to live it - but one that nevertheless exists. My background in Smalltalk made me accustomed to a style where everyone would continuously merge everyone else's changes as they worked. This style makes you aware of what your team mates are doing. In fact, it facilitates communication pretty much when communication is most called for. As always: context. The…

It was a badly run organization - and, as an extension, bad management, bad developers, bad process, bad requirements and bad practices. It wasn't trunk-only that made the project grind to a screeching halt - it was people.

Re: Trunk-Based Development

#174

Post by paul_h »

alkonaut wrote: post #148

In subversion the only way I can possible develop with sanity is in an "unstable trunk". Branch off releases N weeks before shipping, and have only the requirement that trunk passes automated tests while release branches are manually tested. Obviously you don't release more than say once every month or two, but that's more than enough for most. I'm honestly not sure if the site is satire? No one develops in long live…

Not satire - If teams are doing "branch for release", they're doing it a matter of days before the release - https://trunkbaseddevelopment.com/branch-for-release/

Why wouldn't you reconfigure your CI server to also guard prospective and recent release branches??

Also - https://trunkbaseddevelopment.com/youre-doing-it-wrong/#mere...

Re: Trunk-Based Development

#175

Post by paul_h »

glenjamin wrote: post #162
cygned wrote: post #86

We currently use short-lived feature branches, merged via Pull Requests (+ review / automated testing) into the main development line. This way, we can communicate changes in a detailed manner before they are added to the product and make sure there is no unfished or bad code in the main branch. (The dev team is small, 5-8 devs). I don't see (yet?), what benefits TBD would provide in such a setup.

The linked website includes this workflow under their definition of trunk-based-development. As long as your branches are short-lived and make it into the main line rapidly, it appears to be considered equivalent. I've seen some commentators say that this doesn't pass their bar for TBD, but I think it's effectively the same thing. The site does call out "GitHub flow" as being slightly different, but that's because Gi…

Couldn't have said it better myself :)

Re: Trunk-Based Development

#176

Post by paul_h »

notarealdoctor wrote: post #55
whyileft wrote: post #42

If you need to hide feature work behind a flag on prod you're probably doing it wrong. There are a few times when you need to, but features can in most cases be written in a way that they can live inside production before complete. And learning to work like that also has the benefit of aggressively fighting features that drag on forever. There are definitely exceptions, but 9 times out of 10 learning to develop featu…

> There are a few times when you need to, but features can in most cases be written in a way that they can live inside production before complete. That should never, ever, ever be done.

Really? http://techcrunch.com/2011/05/30/facebook-source-code

Re: Trunk-Based Development

#177

Post by sydd »

alkonaut wrote: post #163
sydd wrote: post #151

Earlier quoted context omitted.

If you release only a month or 2 you are doing something really wrong (or need to work based on some insane spec). Read the basics about CI and CD, read the clean code book, read about modern organisation practices (e.g. Github releases several times a day). Releasing every month or so is (thank God) a relic of the old waterfall development times.

We do CI, not CD. Lots of software doesn't do CD and lots of it can't. Games. Embedded. Desktop. Store-apps. In my case it's large desktop software for structural engineering. Customers don't want new versions more than 1-2 times per year because of deployment, training and code compliance requirements. If we bork a release we have had users make a long download+install again. We don't just deploy the fixed one in pr…

You can do CD without releasing, its not pressing the release button that matters. CD means that you can press that button any time. Do small changes, test continuously, work on master.

If you make small changes and test them (using automation - unit tests, integration tests etc) you are catching bugs early, avoiding merge conflict (the most evil operation of them all). This is not my idea, its in the clean code book and its the basic of the CI/CD/TDD disciple.

And you can apply this to projects of all kind - we used it on the server, for iOS projects where we had to wait for Apple for weeks etc.

Re: Trunk-Based Development

#178

Post by paulddraper »

paul_h wrote: post #172
paulddraper wrote: post #158

Earlier quoted context omitted.

If I understand git-flow correctly, it's a trunk (develop) with a release branch (master).

We wrote about that: https://trunkbaseddevelopment.com/alternative-branching-mode...

Guess I should have RTFM.

Well written.

Re: Trunk-Based Development

#179

Post by flukus »

sydd wrote: post #177
alkonaut wrote: post #163

Earlier quoted context omitted.

We do CI, not CD. Lots of software doesn't do CD and lots of it can't. Games. Embedded. Desktop. Store-apps. In my case it's large desktop software for structural engineering. Customers don't want new versions more than 1-2 times per year because of deployment, training and code compliance requirements. If we bork a release we have had users make a long download+install again. We don't just deploy the fixed one in pr…

You can do CD without releasing, its not pressing the release button that matters. CD means that you can press that button any time. Do small changes, test continuously, work on master. If you make small changes and test them (using automation - unit tests, integration tests etc) you are catching bugs early, avoiding merge conflict (the most evil operation of them all). This is not my idea, its in the clean code book…

This is an important distinction. Another one is that just because you aren't deploying to production regularly doesn't mean you aren't deploying to other environments.

Re: Trunk-Based Development

#180

Post by icebraining »

qwer wrote: post #136
icebraining wrote: post #112

Earlier quoted context omitted.

Why can't you automatically merge all the branches for testing? Sure, sometimes it won't cleanly merge, but then again, features behind toggles won't always work well together.

I once wished this were possible too, but in reality it isn't. With n branches there are n! permutations to test. That's a lot of infrastructure to maintain and computing power to spend and you still don't end up with a single team-blessed deployment artifact that can automatically be promoted for manual testing or release. Don't get me wrong, feature-toggles are indeed a pain in the ass, but in my experience cherry-…

And with n feature flags, aren't there also n! permutations to test, that is, each combination of enabled/disabled? If you say no, because you just test features as they get manually enabled, why can't you do the same by manually selecting branches to be merged?
Post reply on HN