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

71–80 of 210 posts

Re: Trunk-Based Development

#71

Post by qwer »

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…

It does, but feature branches become pretty useless at that point. It makes a lot less sense to have a branch for something you plan to merge immediately after the first commit (though my team actually does this just to take advantage of github's PR functionality).

Re: Trunk-Based Development

#72

Post by ZenoArrow »

paul_h wrote: post #66
ZenoArrow wrote: post #49

Correct me if I'm wrong but isn't this just a form of centralised version control? If this is a better approach for many teams, perhaps this an indication that DVCS weren't the silver bullet they were hyped up to be. Aside from that, in my opinion the whole centralised version control vs. decentralised version control, and all the variants thereof, miss the bigger issue. Keeping track of the history of a file, and th…

SemanticMerge mentioned on the site: https://trunkbaseddevelopment.com/game-changers/#plasticscm-... . It got it's name after I blogged about it too - http://paulhammant.com/2013/02/14/features-i-would-love-sour... - and am still owed a beer.

Thanks for the links, I'm glad you identified this as an issue and inspired further development of a solution (though I'm surprised you're owed a beer for such an obvious name, must've taken all of about 5 seconds to think of that one ;-) ).

Also found this article in the comments of your blog to be interesting:

http://blog.plasticscm.com/2013/04/put-your-hands-on-program...

This article you linked to was interesting too, is this a common workflow on CI solutions now?:

https://blog.snap-ci.com/blog/2013/11/07/automatic-branch-tr...

Re: Trunk-Based Development

#73

Post by whyileft »

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

I would say for backend you can get away without feature flags most of the time. But for the frontend, it's almost impossible to ship a new incomplete feature without feature flags

That's actually a very valid point. I was not thinking as much about HTML/CSS as I haven't been involved in a lot of large scale frontend refactors.

Re: Trunk-Based Development

#74

Post by jsolson »

kyrra wrote: post #30
joneholland wrote: post #11

Earlier quoted context omitted.

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.

Google doesn't use perforce anymore. They have a custom in-house SCM that has various interfaces wrapped around it. I'd recommend this video that describes it. https://m.youtube.com/watch?v=W71BTkUbdqE

Piper is awesome, but it's not unreasonable to think of it as Perforce if you designed and built Perforce to scale to handling all of Google in one repo. It has basically the same set of nouns and verbs. citc is the really magical bit, UX wise, as it's like you had a Perforce view set up for our entire repo but never actually had to sync it manually. Just navigate to a file and start hacking.

The paper that corresponds to the talk includes numbers on that (I forget if they're in the video).

http://m.cacm.acm.org/magazines/2016/7/204032-why-google-sto...

(note: I work at Google and absolutely love our SCM and other dev tooling)

Re: Trunk-Based Development

#75

Post by qwer »

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

Re: Trunk-Based Development

#76

Post by dpark »

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.

This is pretty lame. You're both whining about downvotes and calling everyone who disagrees with you old.

I don't know what your concern is with feature flags. Maybe the way you've implemented or used them in the past has been problematic. But when your approach to disagreement is this petty, it makes me think you are unlikely to be able to discuss it meaningfully anyway.

Re: Trunk-Based Development

#77

Post by dpark »

notarealdoctor wrote: post #51
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 means every commit gets built and delivered all the way prod if it passes all tests. I always wondered why a company would allow code to go straight to production, live, affecting customers, without a human giving the OK to release.

Because you should be able to automate that OK. There is generally no verification that a human can do on a computer system that cannot be automated. The only question is whether you're willing to invest enough to fully automate the go/no go decision.

Re: Trunk-Based Development

#78

Post by chvid »

paul_h wrote: post #64
chvid wrote: post #5

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.

Small teams like Google's 25000 devs and QA automators? :)

I think it can work well with maybe 10-20 people.

Depends on how well you software is modularised.

Re: Trunk-Based Development

#79

Post by gaastonsr »

nhumrich wrote: post #52
hamandcheese wrote: post #47

Earlier quoted context omitted.

How does code review fit in to such a workflow? That's also a manual step, but one I and many others consider good and necessary.

According to the article, and my personal experience, you don't commit directly to trunk. Trunk based means that you don't "collaborate" on a branch. So you write your code based off of trunk, once it's ready you commit in a branch, simply for purpose of code review. It gets reviewed, and probably runs an automated build. Once both pass, you merge and it goes through your deployment pipeline. Yes the merge/code revie…

It really is the same. He very much could branched off your branch and once merged just start syncing with master. And I see that better than waiting for your PR to be merged.

Re: Trunk-Based Development

#80

Post by _m7bj »

nhumrich wrote: post #61
hashkb wrote: post #17

Earlier quoted context omitted.

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

All you have to do is enter an email address. It doesn't even have to be a real email.

It's pretty rude to ask every visitor to a free report to hand over contact details. What are you planning to do with all those contact details?

I can only think of plans that range from annoying to malicious. None that are good.

Don't normalize rude behavior. Conditionally free is not free.

Post reply on HN