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

1–10 of 210 posts

Re: Trunk-Based Development

#2

Post by hashkb »

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.

Re: Trunk-Based Development

#3

Post by nhumrich »

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 when I am ready"

Re: Trunk-Based Development

#4

Post by joneholland »

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 but with all work in feature branches that live for less than s day or two, instead of branch by abstraction in the core code. That's it!

Re: Trunk-Based Development

#5

Post by chvid »

This is what I do when I can get away with it. Suitable for smallish teams.

All developers sit in the same branch; changes and conflicts are visible (and resolved) immediately. All work takes place there including bug fixes.

When we branch out for release; the focus is on disabling unwanted features. Actual development work + "hardening" is done in the main trunk before the branch.

Re: Trunk-Based Development

#6

Post by geocar »

I described something that seems very similar years ago[1] (in response to git-flow), however I've since come up with something better: I think knowing how to get things live is important, and the entire development process should reflect that -- too many people have a "code cut" that takes days or even weeks, and that's despite using the latest and greatest CI tools.

A lot of the problems may sound familiar: How do we test something? How do we know it's good enough? We have a UAT step, but it doesn't find all the problems, so do we need more tests? To be more careful?

My approach[2] turns the entire problem into a software problem, and it's proving very successful to me (faster request turnaround, fewer problem reports post-deploy, and so on). Being able to select a "git branch name" for a specific user and get acceptance is powerful.

[1]: https://news.ycombinator.com/item?id=6125964

[2]: https://news.ycombinator.com/item?id=11190540

Re: Trunk-Based Development

#7

Post by geocar »

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…

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.

Re: Trunk-Based Development

#9

Post by nhumrich »

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

Re: Trunk-Based Development

#10

Post by joneholland »

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…

We deploy every commit in master and use short lived feature branches and pull requests.

I would still consider this continuous delivery.

Post reply on HN