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

11–20 of 210 posts

Re: Trunk-Based Development

#11

Post by joneholland »

nhumrich wrote: post #9
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…

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.

Re: Trunk-Based Development

#12

Post by nhumrich »

geocar wrote: post #7
nhumrich wrote: post #3

Earlier quoted context omitted.

You must not understand what CD really means then, because full CD is impossible with feature branches. CD means every commit gets built and delivered all the way prod if it passes all tests. The key word is "continuous" as in, every single commit. Branch based means you only deliver once you merge. Merging is a manual step, so your not doing full-CD. The merge is basically your "trigger" and your doing "delivery whe…

CD is not impossible with feature branches. My live system looks up the branch name in the URL or in a (signed) cookie and checks out the appropriate branch then and there . This is possible because my development system is integrated into my live system.

So your delivering all commits on all branches to prod? That sounds hairy

Re: Trunk-Based Development

#13

Post by perlgeek »

geocar wrote: post #7
nhumrich wrote: post #3

Earlier quoted context omitted.

You must not understand what CD really means then, because full CD is impossible with feature branches. CD means every commit gets built and delivered all the way prod if it passes all tests. The key word is "continuous" as in, every single commit. Branch based means you only deliver once you merge. Merging is a manual step, so your not doing full-CD. The merge is basically your "trigger" and your doing "delivery whe…

CD is not impossible with feature branches. My live system looks up the branch name in the URL or in a (signed) cookie and checks out the appropriate branch then and there . This is possible because my development system is integrated into my live system.

If push to two feature branches, A and B, which one lands in production? both? if so, how? or the last one you pushed? Or the one that finished its build later?

Re: Trunk-Based Development

#14

Post by hashkb »

joneholland wrote: post #10
nhumrich wrote: post #3

Earlier quoted context omitted.

You must not understand what CD really means then, because full CD is impossible with feature branches. CD means every commit gets built and delivered all the way prod if it passes all tests. The key word is "continuous" as in, every single commit. Branch based means you only deliver once you merge. Merging is a manual step, so your not doing full-CD. The merge is basically your "trigger" and your doing "delivery whe…

We deploy every commit in master and use short lived feature branches and pull requests. I would still consider this continuous delivery.

Yes, this is what I think of as CD. Hiding work that isn't ready (or work that may never make it in front of users) behind a flag on prod sounds like extra work for no gain, to me.

Re: Trunk-Based Development

#15

Post by hashkb »

nhumrich wrote: post #3
hashkb wrote: post #2

The suggestion that feature branches hinder CD is just untrue, at least in my experience. To me, this seems like a silly restriction to put on such a critical tool (the scm) which is designed to support unlimited flexibility.

You must not understand what CD really means then, because full CD is impossible with feature branches. CD means every commit gets built and delivered all the way prod if it passes all tests. The key word is "continuous" as in, every single commit. Branch based means you only deliver once you merge. Merging is a manual step, so your not doing full-CD. The merge is basically your "trigger" and your doing "delivery whe…

Anyway the article mentions Continuous Delivery, not Continuous Deployment. Neither means what you say, according to a Puppet Labs blog post, but the latter sometimes does to some people. But that's not what the article says, and so it's not what I'm countering in my comment.

Re: Trunk-Based Development

#16

Post by nhumrich »

joneholland wrote: post #10
nhumrich wrote: post #3

Earlier quoted context omitted.

You must not understand what CD really means then, because full CD is impossible with feature branches. CD means every commit gets built and delivered all the way prod if it passes all tests. The key word is "continuous" as in, every single commit. Branch based means you only deliver once you merge. Merging is a manual step, so your not doing full-CD. The merge is basically your "trigger" and your doing "delivery whe…

We deploy every commit in master and use short lived feature branches and pull requests. I would still consider this continuous delivery.

By "short lived", how short lived? Is the branch only for one developer? Or is it shared? How do you enforce "short lived"? If the branches are not collaborated on, you might be doing trunk based without realizing it.

Re: Trunk-Based Development

#17

Post by hashkb »

rkaregaran wrote: post #8

Puppet Labs’ recently published State of DevOps (2016) report specifically calls out trunk-based development as a leading indicator of high performing organizations [1]. [1] https://puppet.com/resources/white-paper/2016-state-of-devop...

Amount of info required to download free report makes it not free. Can you quote?

Re: Trunk-Based Development

#18

Post by nhumrich »

hashkb wrote: post #14
joneholland wrote: post #10

Earlier quoted context omitted.

We deploy every commit in master and use short lived feature branches and pull requests. I would still consider this continuous delivery.

Yes, this is what I think of as CD. Hiding work that isn't ready (or work that may never make it in front of users) behind a flag on prod sounds like extra work for no gain, to me.

The gain is early integration. If you have more than one branch going on at the same time, they can diverge quite significantly, and merging can cause bugs, or sometimes more work. If you only ever have one feature branch at a time, you might as well be doing trunk based with manual deploys to prod.

Re: Trunk-Based Development

#19

Post by vidanay »

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…

GitFlow and it's derivatives have very poor handling for continued bug fixes of old released versions. It might be great for a truly continuous model such as Facebook and Gmail where there is only "one true version", but in a case where there is a current version and three old versions requiring bug fixes, it fails miserably.

Re: Trunk-Based Development

#20

Post by hashkb »

nhumrich wrote: post #16
joneholland wrote: post #10

Earlier quoted context omitted.

We deploy every commit in master and use short lived feature branches and pull requests. I would still consider this continuous delivery.

By "short lived", how short lived? Is the branch only for one developer? Or is it shared? How do you enforce "short lived"? If the branches are not collaborated on, you might be doing trunk based without realizing it.

>you might be doing trunk based without realizing it.

Then trunk based is poorly named and apt to start a fruitless holy war. Nobody wants too many people on a feature branch, or for one to live too long. (But it happens, like rebranding an entire app or rewriting all the auth code, which is a good thing to be able to do. )

Is there a threshold of time/collaboration that makes it not-CD?

Post reply on HN