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

131–140 of 210 posts

Re: Trunk-Based Development

#131

Post by icebraining »

whyileft wrote: post #70

Yup, as the other comment stated, this is par for the course in modern quality software development. Its actually rather shocking to me to see my comment get downvoted. The quality of the HN audience is declining dramatically. Feels like all we have is a bunch of web agency lifers at this point.

Feature flags are used by essentially every major software company. Hell, the browser you're using to post this has quite a few. A bunch of major software companies use them heavily as well.

You may disagree and think they're terrible, but calling their users just "web agency lifers" is objectively incorrect.

Re: Trunk-Based Development

#132

Post by paul_h »

vemv wrote: post #129
SideburnsOfDoom wrote: post #123

Earlier quoted context omitted.

> Quite false. How do you expect developers to take you seriously when you essentially say "you can't properly do CI/CD with your current approach"? I sure am enjoying CI/CD right now. Do you not understand that the "Integration" in continuous integration literally means "merge to master". Please read the first paragraph https://en.wikipedia.org/wiki/Continuous_integration What you do might work well for you, but if…

These days CI vastly means test-on-commit over anything else. Please google "CI platform" and see how Codeship, Circle, Travis etc self-advertise as CI platforms. None of them require TBD (not even nearly).

Quite correct.

Snap-CI is configurable to test every active branch, on first commit/push - https://trunkbaseddevelopment.com/game-changers/#snap-ci-s-p...

Of course doing that will expose problems that lead the dev team to reconsider Trunk Based Development.

Re: Trunk-Based Development

#133

Post by z3t4 »

I read Drunk-Based Development and was a bit disappointed. I can get awesome ideas while very tired and usually write them down, but a few weeks later, even though I was super exited when I wrote it down, it no longer makes any sense ...

Re: Trunk-Based Development

#134

Post by daenney »

nilliams wrote: post #122
daenney wrote: post #103

Earlier quoted context omitted.

> It's simple but it requires effort and habits. That seem to go against the definition of simple: easily understood or done; presenting no difficulty. That's not to say there aren't any benefits to it or that developing those habits are a waste, but it's not simple. Changing existing or developing new habits is not without difficulty, it takes time, patience and perseverance.

> That seem to go against the definition of simple: easily understood or done; presenting no difficulty. That's not a great definition of 'simple' to apply to software dev. Simple != easy, because easy is inherently about familiarity. See Rich Hickey's excellent talk on the subject [1]. [1] https://www.infoq.com/presentations/Simple-Made-Easy

That talk doesn't relate to the whole discipline of software development though. He's mostly arguing that if you chose ease over simplicity in your programming/code it can heavily effect the output of your work and its long term viability. It's about not introducing complexity in the design and your product.

But this is about the process and workflows of collaboration on code, not the code or the product itself. Some of these concepts certainly apply but just because it is in the realm of software development doesn't mean that particular definition always applies.

Re: Trunk-Based Development

#135

Post by Sir_Substance »

brianwawok wrote: post #97
_m7bj wrote: post #80

Earlier quoted context omitted.

It's pretty rude to ask every visitor to a free report to hand over contact details. What are you planning to do with all those contact details? I can only think of plans that range from annoying to malicious. None that are good. Don't normalize rude behavior. Conditionally free is not free.

It's their right as a producer to require email to view their content. It's your right as a consumer to not want to make that trade. Not rude. Rude is posting the raw file link to subvert the agreement or complain about it on hacker news.

You have a very odd view of rights. It's /within their means/ as a producer to require email to view their content. Just because you can do something doesn't make it your right to do something. Doesn't make it wrong to do it either, but that's god damn miles from a right.

In addition, just because you can do something doesn't mean you should, and it's within my means to assert that anyone who asks for my contact information but doesn't know me personally /definitely/ wants to spam me, there's no other reason for them to ask for that information.

Being polite, spamming is rude. Being rude, people who send or enable spam are worthless scum. I have no time for anyone who chooses willfully to be part of that cycle.

My freedom to express that opinion actually /is/ a right[1].

[1] http://www.un.org/en/universal-declaration-human-rights/

Re: Trunk-Based Development

#136

Post by qwer »

icebraining wrote: post #112
einrealist wrote: post #87

Earlier quoted context omitted.

With TBD you can reduce the overhead of coordination between committers. Edit for clarification: "Branching in code", á la Feature Toggles is much better, because everything around it can be automated. With CVS branches, you shift that process into an earlier development stage where you need more human collaboration. So TBD can shift the focus of collaboration to things that matter more: the code.

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-picking branches to merge really is much much worse.

Re: Trunk-Based Development

#137

Post by qwer »

paulddraper wrote: post #127
paul_h wrote: post #126

Earlier quoted context omitted.

> Those have release branches. Some Trunk Based Development teams do "branch for release" https://trunkbaseddevelopment.com/branch-for-release/ and some do "release from trunk" https://trunkbaseddevelopment.com/release-from-trunk/ Google gave numbers themselves - 95% of their devs are in one big trunk (formerly perforce, but re-written in-house in 2012). It's true that the open source facing teams are outside that, a…

You can have long lived release branches in "trunk-based development"?!? In that case, I guess I haven't ever seen a branching strategy that wasn't "trunk-based." What would that even be?

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

Re: Trunk-Based Development

#139

Post by paul_h »

paulddraper wrote: post #127
paul_h wrote: post #126

Earlier quoted context omitted.

> Those have release branches. Some Trunk Based Development teams do "branch for release" https://trunkbaseddevelopment.com/branch-for-release/ and some do "release from trunk" https://trunkbaseddevelopment.com/release-from-trunk/ Google gave numbers themselves - 95% of their devs are in one big trunk (formerly perforce, but re-written in-house in 2012). It's true that the open source facing teams are outside that, a…

You can have long lived release branches in "trunk-based development"?!? In that case, I guess I haven't ever seen a branching strategy that wasn't "trunk-based." What would that even be?

It depends on whether the branch ever merges back to the trunk or not.

Re: Trunk-Based Development

#140

Post by xorcist »

If there was indeed a superior way of developing software, why doesn't anyone take this knowledge and out-compete for example Linux? It has literally hundreds of branches of all kinds (stable branches, feature branches, test branches), this should be easy pickings! Or out-compete Google or Microsoft which, contrary to whats said in this article, use branches and probably in all their big projects. Sorry, I don't buy it. I suspect that if you are religiously against branches you will just have to re-invent them by some other name.
Post reply on HN