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

191–200 of 210 posts

Re: Trunk-Based Development

#191

Post by cwills »

We have a smallish team working on web apps and use a trunk-based-development branching strategy. Not really to do with helping CI/CD.

The advantage we see is that new developers can start developing as soon as they clone the repository, without needing to switch to the 'development' branch. This is particularly useful when on boarding new developers who are inexperienced with Git. I found that when using Git Flow that the (stable) master branch frequently ends up out-of-date when developers are required to remember to merge into it releases into it.

Diagram of our branching strategy: https://gist.github.com/CameronWills/abf9e307669b1005c88ef82...

Re: Trunk-Based Development

#192

Post by dang »

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…

We detached this subthread from https://news.ycombinator.com/item?id=13514538 and marked it off-topic.

Re: Trunk-Based Development

#193

Post by stcredzero »

chrisseaton wrote: post #181
stcredzero wrote: post #144

Earlier quoted context omitted.

Trunk-only is a reality. Not a reality some of us would want to live it - but one that nevertheless exists. My background in Smalltalk made me accustomed to a style where everyone would continuously merge everyone else's changes as they worked. This style makes you aware of what your team mates are doing. In fact, it facilitates communication pretty much when communication is most called for. As always: context. The…

How does a team of Smalltalk developers work? How do you merge the binary Smalltalk program image?

Most places I worked "built" by loading the release configuration, then saving off the image. That's often all there is to it. At one job, some pre-population scripts were also run for menus and drop downs.

Re: Trunk-Based Development

#194

Post by foo101 »

Sir_Substance wrote: post #135
brianwawok wrote: post #97

Earlier quoted context omitted.

It's their right as a producer to require email to view their content. It's your right as a consumer to not want to make that trade. Not rude. Rude is posting the raw file link to subvert the agreement or complain about it on hacker news.

You have a very odd view of rights. It's /within their means/ as a producer to require email to view their content. Just because you can do something doesn't make it your right to do something. Doesn't make it wrong to do it either, but that's god damn miles from a right. In addition, just because you can do something doesn't mean you should, and it's within my means to assert that anyone who asks for my contact info…

> My freedom to express that opinion actually /is/ a right.

Sure, but https://xkcd.com/1357/

Re: Trunk-Based Development

#195

Post by pjmlp »

chrisseaton wrote: post #181
stcredzero wrote: post #144

Earlier quoted context omitted.

Trunk-only is a reality. Not a reality some of us would want to live it - but one that nevertheless exists. My background in Smalltalk made me accustomed to a style where everyone would continuously merge everyone else's changes as they worked. This style makes you aware of what your team mates are doing. In fact, it facilitates communication pretty much when communication is most called for. As always: context. The…

How does a team of Smalltalk developers work? How do you merge the binary Smalltalk program image?

With time, Smalltalk also got its own version control tooling.

Monticello for example,

http://www.wiresong.ca/monticello/

Re: Trunk-Based Development

#196

Post by einrealist »

icebraining wrote: post #180
qwer wrote: post #136

Earlier quoted context omitted.

I once wished this were possible too, but in reality it isn't. With n branches there are n! permutations to test. That's a lot of infrastructure to maintain and computing power to spend and you still don't end up with a single team-blessed deployment artifact that can automatically be promoted for manual testing or release. Don't get me wrong, feature-toggles are indeed a pain in the ass, but in my experience cherry-…

And with n feature flags, aren't there also n! permutations to test, that is, each combination of enabled/disabled? If you say no, because you just test features as they get manually enabled, why can't you do the same by manually selecting branches to be merged?

Yes, that complexity does not go away. But you only need one delivery pipeline, with one test/staging environment. Toggling and running acceptance tests against the variations can be automated, but is viable when done manually.

Re: Trunk-Based Development

#197

Post by susam »

icebraining wrote: post #180
qwer wrote: post #136

Earlier quoted context omitted.

I once wished this were possible too, but in reality it isn't. With n branches there are n! permutations to test. That's a lot of infrastructure to maintain and computing power to spend and you still don't end up with a single team-blessed deployment artifact that can automatically be promoted for manual testing or release. Don't get me wrong, feature-toggles are indeed a pain in the ass, but in my experience cherry-…

And with n feature flags, aren't there also n! permutations to test, that is, each combination of enabled/disabled? If you say no, because you just test features as they get manually enabled, why can't you do the same by manually selecting branches to be merged?

With n feature flags, there are 2^n possibilities to test.

Re: Trunk-Based Development

#198

Post by crdoconnor »

prodigal_erik wrote: post #183
crdoconnor wrote: post #88

Earlier quoted context omitted.

I would hesitate to proscribe a "one true way" as well but the longer I develop the more convinced I am that a having branch lives longer than a few days indicates a serious underlying problem (usually a lack of test coverage or faith in said tests).

In 20 years I've never worked on a project that had a test suite strong enough to merit blind faith. Usually the weak points are * realistic test input: either you carefully scrub actual production traffic and replay it (these require a ton of setup that doesn't age well), or you guess what you think users are doing and create dummy requests (and miss anything wacky you didn't know users do) * load & perf: it's rare…

* Lack of realistic test input is usually a problem caused by over-reliance on unit testing or lack of monitoring feedback.

* UX review and load & performance testing are usually things that we engage in regularly on trunk or the developer/code reviewer flags up ("this change has load implications/this change requires a UX review").

* "Microsoft famously got bitten by moving away from manual testing" - I'd never advocate eliminating manual testing entirely, just that it should be A) never repetitive, B) not a gatekeeper, C) always exploratory.

>We usually had best-effort integration tests, but they never caught everything,

Nothing ever catches everything but IMHO continuous delivery, short-lived branches, good monitoring and regular exploratory testing, load/perf testing on trunk is the best way to catch as much as possible.

I've started experimenting with integration tests that generate reports with screenshots and story steps, as well, so that there's a tighter UX feedback.

Re: Trunk-Based Development

#199

Post by UK-AL »

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…

What do you think unpushed/uncommited changes on your local machine. They are basically feature branches.

Re: Trunk-Based Development

#200

Post by UK-AL »

ungzd wrote: post #108

TLDR: instead of using diffs of changed lines in branches, use 'if' statements in code to make Enterprise Continuous Integration gods happy.

The advantages of feature branches is that you can turn them on and off easily without trying merge in, or revert and dealing with the resultant conflicts this can cause.

Feature switches also have more advanced features like being able targeting specific users, if you want a gradual rollout.

We use both feature branches and feature switches, since branches short be very short lived. However large areas of development require months.

Post reply on HN