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

81–90 of 210 posts

Re: Trunk-Based Development

#81

Post by dursk »

qwer wrote: post #75
vemv wrote: post #22

> Trunk Based Development is a key enabler of Continuous Integration, and by extension Continuous Delivery. 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. Trunk-based development seems to rely heavily on feature flags, which are a huge source of complexity and inconsistency. Even whe…

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

If you learn how to break features down into small chunks, you can commit to master near-daily while still doing git flow.

Re: Trunk-Based Development

#82

Post by paul_h »

joneholland wrote: post #4

Trunk based development works well on any scm that sucks at branching. Perforce, subversion etc. But, on git, using GitHub-Flow is far superior. The two poster children for TBD do not use git. Don't cargo cult their process without understanding the unique problems they have that you don't. Edit: downvotes on HN? This isn't Reddit, and I'm advocating github flow, not git flow. GitHub flow is trunk based development b…

Which two poster children?

Trunk Based Development is also "all work in feature branches that live for less than a day or two". One small difference to Github-flow though: https://trunkbaseddevelopment.com/alternative-branching-mode...

Re: Trunk-Based Development

#83

Post by cat199 »

With a sentence like:

" It has been a lesser known branching model of choice since the mid-nineties, and considered tactically since the eighties. "

Given:

The Release Engineering of 4.3BSD https://docs.freebsd.org/44doc/papers/releng.html 1989

concerning a key software system and part of software history, released in 1986, which states:

" For the 4.3BSD release, certain users had permission to modify the master copy of the system source directly. ... The development phase continues until CSRG decides that it is appropriate to make a release. "

,that the rcs tools of the time basically didn't even support branches natively, and this model is followed to this day by the direct descendants of this project

I'm prone to think that.. well. Hmm.

Re: Trunk-Based Development

#84

Post by dastbe »

joneholland wrote: post #11
nhumrich wrote: post #9

Earlier quoted context omitted.

Who are your two poster children? Because in my mind it's Amazon and Google, who both use git

In the article it was google (perforce) and Facebook (mercurial with hacks). Both are massive mono repos. At Amazon they were mostly perforce when I was there. Granted that was a few years back.

Amazon (today) maintains a git repo per package, though in theory there's no reason why it has to stay git (or even be homogenous). Each application is a set of versioned artifacts that can be updated, forked, or merged together so long as the whole set builds together.

Re: Trunk-Based Development

#85

Post by lotyrin »

hashkb wrote: post #38
mbrock wrote: post #32

Earlier quoted context omitted.

It seems like many people are unaware that "continuous integration" since its inception has meant pretty much the same thing as "trunk based development." Wikipedia's definition: "In software engineering, continuous integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day."

That sounds like it allows for feature branches to me. Edit: anyway, isn't that extremely pedantic? I've known literally hundreds of companies that say "we are using CI" when what they mean is "master is continuously tested + deployed"... is there a name for that we should all start using? I'm not trying to diminish the awesomeness of "real" CD that some of you out there appear to be doing and proud of preserving the…

TBD as described here also allows for feature branches (but they must be short lived and owned/worked on by a single developer -- which seems reasonable to me).

I think people are seeing TBD as "no-branches ever" and that is not it's goal or design.

Re: Trunk-Based Development

#86

Post by cygned »

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.

Re: Trunk-Based Development

#87

Post by einrealist »

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.

Re: Trunk-Based Development

#88

Post by crdoconnor »

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…

I would hesitate to proscribe a "one true way" as well but the longer I develop the more convinced I am that a having branch lives longer than a few days indicates a serious underlying problem (usually a lack of test coverage or faith in said tests).

Re: Trunk-Based Development

#89

Post by DrJones1098 »

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.

I like this best.

It enables you to build your feature and then squash the commits into one idempotent feature commit which keeps commit clutter out of the git logs.

Just keeping your branch rebased daily, one will have minimal problems even on big teams.

I personally love developing on my own branch and having the freedom to experiment without messing stuff up.

Re: Trunk-Based Development

#90

Post by __derek__ »

qwer wrote: post #75
vemv wrote: post #22

> Trunk Based Development is a key enabler of Continuous Integration, and by extension Continuous Delivery. 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. Trunk-based development seems to rely heavily on feature flags, which are a huge source of complexity and inconsistency. Even whe…

> 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)

Post reply on HN