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

121–130 of 210 posts

Re: Trunk-Based Development

#121

Post by qwer »

pdonis wrote: post #91
dursk wrote: post #81

Earlier quoted context omitted.

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

> If you learn how to break features down into small chunks If that's possible. What if there are some features for which it isn't?

Obviously if you can't break it up into smaller pieces, you can't regularly integrate smaller pieces. That's a tautology.

With that said, I've been doing this for over ten years and haven't come across that scenario. You can easily figure out all kinds of tricks to break things down, but usually only after you believe in the value of it.

Re: Trunk-Based Development

#122

Post by nilliams »

daenney wrote: post #103
vemv wrote: post #44

Earlier quoted context omitted.

It's simple but it requires effort and habits. Many developers work using the opposite mindset, they prefer to trade short-term easiness for long-term complexity (which is kinda valid), instead of battling complexity upfront.

> It's simple but it requires effort and habits. That seem to go against the definition of simple: easily understood or done; presenting no difficulty. That's not to say there aren't any benefits to it or that developing those habits are a waste, but it's not simple. Changing existing or developing new habits is not without difficulty, it takes time, patience and perseverance.

> That seem to go against the definition of simple: easily understood or done; presenting no difficulty.

That's not a great definition of 'simple' to apply to software dev. Simple != easy, because easy is inherently about familiarity. See Rich Hickey's excellent talk on the subject [1].

[1] https://www.infoq.com/presentations/Simple-Made-Easy

Re: Trunk-Based Development

#123

Post by SideburnsOfDoom »

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.

Do you not understand that the "Integration" in continuous integration literally means "merge to master". Please read the first paragraph https://en.wikipedia.org/wiki/Continuous_integration

What you do might work well for you, but if you build long-lived branches then it's not CI. Let's not call it something that it's not: words have meaning if we are to communicate, and we're not doing post-truth software development.

Re: Trunk-Based Development

#124

Post by qwer »

__derek__ wrote: post #120
qwer wrote: post #118

Earlier quoted context omitted.

Are you questioning the daily part (continuous) or the mainline part (integration)? I'm also interested in your better source. Every book I've read on the subject and the top 4 search results on google say the same thing.

I'm not an expert, and I've read no books on the subject, so I'll refrain from suggesting sources. The implication of my comment was that it's disingenuous to use that link as proof when it's marked with the equivalent of a FIXME.

First off, I have no motive to be disingenuous. I really don't care how you collaborate on software with your team.

Secondly, CI itself is considered a best practice. I don't know how you could expect wikipedia to mark it as anything else?

Here's the top link from google if you really care to learn and aren't just here to be a contrarian: https://www.thoughtworks.com/continuous-integration . There is a wealth of information on this subject that I promise all says the same thing. We can argue about whether or not CI is useful, but the practice of integrating continuously is in all the literature as well as the name itself.

Re: Trunk-Based Development

#125

Post by twic »

ithkuil wrote: post #98
chvid wrote: post #78

Earlier quoted context omitted.

I think it can work well with maybe 10-20 people. Depends on how well you software is modularised.

I assure you it works well with 25000 people, I've worked in such an environment. It seems to me that in the various threads I read here that there seems to be a bit of misunderstanding. If you work on short lived feature branches and merge them to trunk/master and other people branch new feature branches from trunk/master and so on you might be just doing TBD without calling it that way. Many things are just common…

> you might be just doing TBD without calling it that way

I think this happens an astounding amount. In particular, i think Git Flow is TBD with the names swizzled.

As far as i know, all the source control disciplines that people seriously advocate involve:

1. Developers working on local copies of the code

2. A shared copy of the code where developers integrate their work when they're done

3. A copy of the code used to make releases, which is refreshed or recreated from the shared copy

These copies get different names, which are meaningless labels. In TBD, the shared copy is called 'trunk', and the release copy a 'release branch'. In Flow, the shared copy is 'develop' and the release copy is 'master'. They're just names. They don't matter.

The precise mechanism for moving work from local copies to the shared copy varies, but not in a way which really matters. In TBD, developers usually push straight to the trunk. If they're doing XP, they've done code review via pairing. In some teams, there might be pre-merge code review through a tool like Gerrit, Reviewboard, Phabricator, or some such, but still with an expectation of a merge happening quickly. In Flow, i guess there are pull reviews, but those are basically the same, a code review before merging. The Not Rocket Science Rule is this, but enforced by a robot [1].

The mechanism for moving work from the shared copy to the release copy varies a bit more. Strict CD shops release the trunk, but they will only push the latest point on the trunk which has passed all the checks, which is a bit like having an implicit branch. Conventional TBD cuts release branches. Flow does, that, and then adds a bit of a dance around merging individual release branches into the long-lived master branch, but it doesn't ultimately matter, because any changes made on an earlier release branch have already been merged back into develop. There's variation in where you fix urgent bugs: on the shared copy, followed by a copy to the release copy, or on the release copy, followed by a copy to the shared copy. I'm not sure that this is very significant.

Which leaves the only significant tuneables being how often developers integrate their changes, and how often the team makes releases. If you integrate often, you get easy merges and rapid integration feedback. If you integrate infrequently, you don't get those things. If you integrate more frequently than you release, then you will need disciplined incremental development, feature toggles, or some other way of making incomplete features unavailable in production.

[1] http://graydon2.dreamwidth.org/1597.html

Re: Trunk-Based Development

#126

Post by paul_h »

paulddraper wrote: post #117

> Google do Trunk Based Development and they have 25000 developers and QA automators in that trunk For some stuff, but Is Android trunk-only? No. Is V8 trunk-only? No. Is Chrome trunk-only? No. Those have release branches. --- Some software works with trunk-only paradigm, some does not. A rule of thumb is whether your customer-facing distribution is SaaS/web-based. If you're making Google Search, you do it in a trunk…

> Those have release branches.

Some Trunk Based Development teams do "branch for release" https://trunkbaseddevelopment.com/branch-for-release/ and some do "release from trunk" https://trunkbaseddevelopment.com/release-from-trunk/

Google gave numbers themselves - 95% of their devs are in one big trunk (formerly perforce, but re-written in-house in 2012). It's true that the open source facing teams are outside that, and have processes that are less lock-step than what they do in-house.

Android - Samsung, on each release (maybe not anymore), used to check all the composite parts of Android into one big trunk for themselves. Back into their Perforce.

> If you're making Google Chrome, you don't.

There's nothing stopping the Chrome team from doing Trunk Based Development on Github, and accepting unsolicited pull requests like any other team.

Re: Trunk-Based Development

#127

Post by paulddraper »

paul_h wrote: post #126
paulddraper wrote: post #117

> Google do Trunk Based Development and they have 25000 developers and QA automators in that trunk For some stuff, but Is Android trunk-only? No. Is V8 trunk-only? No. Is Chrome trunk-only? No. Those have release branches. --- Some software works with trunk-only paradigm, some does not. A rule of thumb is whether your customer-facing distribution is SaaS/web-based. If you're making Google Search, you do it in a trunk…

> Those have release branches. Some Trunk Based Development teams do "branch for release" https://trunkbaseddevelopment.com/branch-for-release/ and some do "release from trunk" https://trunkbaseddevelopment.com/release-from-trunk/ Google gave numbers themselves - 95% of their devs are in one big trunk (formerly perforce, but re-written in-house in 2012). It's true that the open source facing teams are outside that, a…

You can have long lived release branches in "trunk-based development"?!?

In that case, I guess I haven't ever seen a branching strategy that wasn't "trunk-based." What would that even be?

Re: Trunk-Based Development

#128

Post by devonkim »

brianwawok wrote: post #114
crdoconnor wrote: post #106

Earlier quoted context omitted.

I've done that. It signalled that the customer had a lack of faith in the stability of our releases. In our case it was a valid concern (our team had a pretty awful track record).

Apparently you have never sold to a fortune 500? Many require bug fixes only of your app for X years. They don't care about new versions. Nothing about faith but about their priority. Using the latest and greatest is not their priority.

The F500 is incredibly varied in their requirements even within the same company. I've seen demand for new features and long term, keep-everything-the-same-as-day-one from the same group for different services / products. Paying more money to keep things from not changing or for not adding features is something unique to enterprise environments though.

Re: Trunk-Based Development

#129

Post by vemv »

SideburnsOfDoom wrote: post #123
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. Do you not understand that the "Integration" in continuous integration literally means "merge to master". Please read the first paragraph https://en.wikipedia.org/wiki/Continuous_integration What you do might work well for you, but if…

These days CI vastly means test-on-commit over anything else.

Please google "CI platform" and see how Codeship, Circle, Travis etc self-advertise as CI platforms. None of them require TBD (not even nearly).

Re: Trunk-Based Development

#130

Post by SideburnsOfDoom »

vemv wrote: post #129
SideburnsOfDoom wrote: post #123

Earlier quoted context omitted.

> 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. Do you not understand that the "Integration" in continuous integration literally means "merge to master". Please read the first paragraph https://en.wikipedia.org/wiki/Continuous_integration What you do might work well for you, but if…

These days CI vastly means test-on-commit over anything else. Please google "CI platform" and see how Codeship, Circle, Travis etc self-advertise as CI platforms. None of them require TBD (not even nearly).

> These days CI vastly means test-on-commit over anything else.

Quite false. That is a miscommunication.

I know what those "CI servers" do, I have worked with a few of them them daily for years and had this exact same issue come up. These tools enable the continuous integration workflow, and lately they also enable other workflows such as "build and test the branches but don't integrate".

If that's what you do fine, but let's not confuse it with something that it is not. Words have meaning. CI is not a tool, it's in how you use the tools.

But if you still think that wikipedia is wrong, I suggest that you edit it. Good luck.

Post reply on HN