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

31–40 of 210 posts

Re: Trunk-Based Development

#31

Post by whyileft »

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…

Because any long running feature branch can just live in a different repo until its ready to merge. There is a reason they are called branches not trunks. Except for rare exceptions developers should be able to break up features in a way that they can be continuously integrated during development.

Re: Trunk-Based Development

#32

Post by mbrock »

hashkb wrote: post #29
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…

I'm on your side but my comment (yours is better) faced opposition so: They redefine CD and then say nothing else is it, and you aren't doing it.

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

Re: Trunk-Based Development

#33

Post by nhumrich »

hashkb wrote: post #24
nhumrich wrote: post #18

Earlier quoted context omitted.

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.

Rebase early and often and this isn't an issue. Some see this as a chore, but I view it as taking advantage of the tool's power. You resolve the same set of conflicts as you would merging, but (as you say) earlier. Edit: I don't think anyone was trying to imply a single allowed feature branch at a time; we can probably all easily agree that's basically no different than working on master.

Yes, rebase early and often works great. But if your branch includes a major refactor, your going to find yourself editing others code to get your rebase to work. That just increases your own scope. But yes, rebase often is often a very viable strategy. In practice though, I find very few that actually do it because it becomes painful when your branch lives too long simply because business isn't ready to ship something

Re: Trunk-Based Development

#34

Post by shawn-butler »

hashkb wrote: post #17
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?

I think this is the relevant portion for which you are looking:

"We found that having branches or forks with very short lifetimes (less than a day) before being merged into trunk, and less than three active branches in total, are important aspects of continuous delivery, and all contribute to higher performance. So does merging code into trunk or master on a daily basis. Teams that don’t have code freeze periods (when people can’t merge code or pull requests) also achieve higher performance."

Re: Trunk-Based Development

#35

Post by mpdehaan2 »

Developing on master is something I favor, with tagging for releases, though it makes sense to create release branches if you are delivering software packages (that others will install) and not just deploying it to .com websites. Hotfixes can then be applied to both the maintaince branch and master.

Re: Trunk-Based Development

#36

Post by jessaustin »

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…

So write the tests first; isn't that what we're supposed to do anyway? That way the branch doesn't move to prod on commit, because it isn't passing the tests yet.

BTW "commit" is also a "manual step".

Re: Trunk-Based Development

#37

Post by Horba »

vidanay wrote: post #19
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.

I've implemented GitFlow with multiple support versions. We just added a "version" dimension to each of the main branches.

1.1/master 1.1/release 1.1/development

1.2/master 1.2/release 1.2/development

When we fix bugs in 1.x, we work off 1.1/development and merge into all later versions.

This doesn't fit for a "web" or "continuous delivery" model. It does fit very well for software houses with many customers on 6 monthly upgrade / development cycles.

Re: Trunk-Based Development

#38

Post by hashkb »

mbrock wrote: post #32
hashkb wrote: post #29

Earlier quoted context omitted.

I'm on your side but my comment (yours is better) faced opposition so: They redefine CD and then say nothing else is it, and you aren't doing it.

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

Re: Trunk-Based Development

#39

Post by nhumrich »

geocar wrote: post #25
nhumrich wrote: post #12

Earlier quoted context omitted.

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

How many commits do you do in a day? The hardest part is figuring out how to do this without a map.

On a big team, potentially 100's. But if your delivering all commits regardless of branches, why even have branches?

Re: Trunk-Based Development

#40

Post by Tepix »

hashkb wrote: post #17
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?

Try this link:

https://puppet.com/system/files/2016-06/2016%20State%20of%20...

Post reply on HN