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

111–120 of 210 posts

Re: Trunk-Based Development

#111

Post by debaserab2 »

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…

> EDIT: The downvoting system on HN optimizes for older, over the hill developers as is shown here once again.

Or that making gross generalizations like yours and speaking in absolutes demonstrates lack of experience and immaturity.

Re: Trunk-Based Development

#112

Post by icebraining »

einrealist wrote: post #87
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.

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.

Re: Trunk-Based Development

#113

Post by paul_h »

joneholland wrote: post #109
antoncohen wrote: post #105

I think some people are getting confused about terminology between Trunk Based Development[1], Git Flow[2], and GitHub Flow[3]. TBD and GitHub Flow are nearly identical, basically if you use TBD on GitHub you use GitHub Flow. Git Flow (not GitHub Flow) is a model that is all about cutting releases, and supporting bug fixes to releases. Git Flow is nonsensical when doing Continuous Delivery[4] of a web application. If…

This is all good, if you are on git. Like I said in my other downvoted post... too many TBD zealots look at big companies that use it sans branches, and assume that it is the one true way, instead of understanding the larger picture (branches outside of git suck, these companies don't use git for various reasons)

Many of Google's 25000 Trunk-Based-Developers use Git on their local deevloper workstations. They choose their own workflow on their own machine, and then cooperate with the Mondrian submission rules when attempting to get their commit(s) through code review and automated tests/lint/findbugs etc.

Re: Trunk-Based Development

#114

Post by brianwawok »

crdoconnor wrote: post #106
brianwawok wrote: post #93

Earlier quoted context omitted.

How do you support a 3 year LTS branch for enterprise customers without long lived branches?

I've done that. It signalled that the customer had a lack of faith in the stability of our releases. In our case it was a valid concern (our team had a pretty awful track record).

Apparently you have never sold to a fortune 500? Many require bug fixes only of your app for X years. They don't care about new versions. Nothing about faith but about their priority. Using the latest and greatest is not their priority.

Re: Trunk-Based Development

#115

Post by icebraining »

crdoconnor wrote: post #106
brianwawok wrote: post #93

Earlier quoted context omitted.

How do you support a 3 year LTS branch for enterprise customers without long lived branches?

I've done that. It signalled that the customer had a lack of faith in the stability of our releases. In our case it was a valid concern (our team had a pretty awful track record).

Well, sometimes the lack of stability is purposeful - new features are added, old features are deprecated, etc. How do you deal with that?

Re: Trunk-Based Development

#116

Post by cygned »

einrealist wrote: post #87
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.

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.

I am very concerned that feature toggles add unnecessary complexity to the code.

With Lisp Macros, for example, that would actually be quite elegant but in a language like JavaScript, we'd end up with a bunch of if'a here and there, wouldn't we? One might simplify it a bit with a different architecture, though.

Re: Trunk-Based Development

#117

Post by paulddraper »

> Google do Trunk Based Development and they have 25000 developers and QA automators in that trunk

For some stuff, but

Is Android trunk-only? No.

Is V8 trunk-only? No.

Is Chrome trunk-only? No.

Those have release branches.

---

Some software works with trunk-only paradigm, some does not. A rule of thumb is whether your customer-facing distribution is SaaS/web-based.

If you're making Google Search, you do it in a trunk. If you're making Google Chrome, you don't.

Re: Trunk-Based Development

#118

Post by qwer »

__derek__ wrote: post #90
qwer wrote: post #75

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. Quite true actually! : https://en.wikipedia.org/wiki/Continuous_integration#Everyon...

That's in a "Best Practices" section with this note at the top: > This section contains instructions, advice, or how-to content. The purpose of Wikipedia is to present facts, not to train. Please help improve this article either by rewriting the how-to content or by moving it to Wikiversity, Wikibooks or Wikivoyage. (May 2015)

Are you questioning the daily part (continuous) or the mainline part (integration)?

I'm also interested in your better source. Every book I've read on the subject and the top 4 search results on google say the same thing.

Re: Trunk-Based Development

#119

Post by crdoconnor »

brianwawok wrote: post #114
crdoconnor wrote: post #106

Earlier quoted context omitted.

I've done that. It signalled that the customer had a lack of faith in the stability of our releases. In our case it was a valid concern (our team had a pretty awful track record).

Apparently you have never sold to a fortune 500? Many require bug fixes only of your app for X years. They don't care about new versions. Nothing about faith but about their priority. Using the latest and greatest is not their priority.

We were selling to Fortune 500s.

The upgrade paranoia only kicked in when they were subjected to broken releases and had to roll back.

Re: Trunk-Based Development

#120

Post by __derek__ »

qwer wrote: post #118
__derek__ wrote: post #90

Earlier quoted context omitted.

That's in a "Best Practices" section with this note at the top: > This section contains instructions, advice, or how-to content. The purpose of Wikipedia is to present facts, not to train. Please help improve this article either by rewriting the how-to content or by moving it to Wikiversity, Wikibooks or Wikivoyage. (May 2015)

Are you questioning the daily part (continuous) or the mainline part (integration)? I'm also interested in your better source. Every book I've read on the subject and the top 4 search results on google say the same thing.

I'm not an expert, and I've read no books on the subject, so I'll refrain from suggesting sources. The implication of my comment was that it's disingenuous to use that link as proof when it's marked with the equivalent of a FIXME.
Post reply on HN