4 ms·

After a couple of decades in the Danish software industry I've come to accept that there is only trunk-based development (COME AT ME!). Feature branches, set re

by devjab 1y ago

After a couple of decades in the Danish software industry I've come to accept that there is only trunk-based development (COME AT ME!). Feature branches, set releases and so on are fake safety gaps that people add when they don't trust themselves and/or their developers. These days I view it similar to someone who won't deploy changes on fridays because they fear for their weekend. If you're too afraid to deploy on a friday, then you should not be allowed to deploy on a monday. Similarily, if you're not brave enough to push changes to production, then your changes aren't ready. Of course I don't actually think there is a religion on how to do these things, but I've never seen any particular quality added by people doing quarterly releases from a feature branch. For the most part I think this part at the very beginning of the article explains a lot of the reason as to why that is: > When we do trunk-based development, the WIP we commit gets used, before any actual user sees it, by our whole team. In my eyes all of it comes down to management much more than deployment strategies. The disadvantage of feature branching is that it's very easy for management to cut costs on testing. The disadvantage of trunk-based development is that it requires functional teams of people who can actually work together and accept the "norms".

urban_winter 1y ago
Our team has thorough, high quality, automated tests. In the past 5 years we have never released such a badly broken system that emergency remedial work was required. We still don't release on Fridays. It's just common sense, risk management and (most importantly) respect for the developers home and family time.
- devjab 1y ago
  I'd argue that it depends on your users. From a business perspective, it's a lot safer for us to release on fridays because failures would not affect a lot of people over the weekend. Of course I do live in a country where you'd have to agree to fix it over the weekend, and if you do, you'd be compensated with new days off + money.
tsimionescu 1y ago
Having literally no branches might work for tiny projects, but none of this is the case for any decently-sized software. If you want to release a piece of software to a customer who will be using it as-is for some time (which is one possible business model), then you need a version of your software where all features that the customer sees are working well. To do that, you need to fix even minor bugs in those features without adding any (visible) new features to the product. However, this doesn't scale. You can't pause all development of new features while someone is re-aligning a few UI elements and cleaning up error messages that were too confusing. So, you have to create a split in the software: one part is getting ready to ship, another is work in progress for future releases. Now, you can create this split using git branches, or using feature flags. So yes, trunk based development can work, you can absolutely build up the new experimental features into the software you're about to ship, but you'll have to hide them behind a feature flag that is disabled - a runtime branch. Or, you can have a release branch where only bug fixes are allowed, and submit major new work on the main branch. There are pros and cons to either solution, but whatever you do, you need stable vs unstable branches somewhere. And, of course, sometimes you'll have to release hotfixes, and there you won't get away without a true SCM branch, since you can't just give your customers your latest and greatest software just to patch a security issue in libcurl for a 2 year old release.
- deleted 1y ago
  [deleted]
beingfit 1y ago
> The disadvantage of feature branching is that it's very easy for management to cut costs on testing. Have to agree with this. In a large (lower than 2/3rd in the Fortune 500 list) company with cost cutting as a constant mantra, our ever shrinking team hasn’t had a testing/QA team for several years. We never got to automating a lot of tests either. The developers create something and test it manually as per their limited knowledge. Then it’s the end users who do the bulk of the testing.
ido 1y ago
> When we do trunk-based development, the WIP we commit gets used, before any actual user sees it, by our whole team. And of course internal teams love also doing QA on the side of their existing jobs ;) I think that’s fair enough to ask from developers and project/product managers but a lot of others on the team basically have to suffer lower productivity to test your code.

by devjab 1y ago

urban_winter 1y ago

Our team has thorough, high quality, automated tests. In the past 5 years we have never released such a badly broken system that emergency remedial work was required. We still don't release on Fridays. It's just common sense, risk management and (most importantly) respect for the developers home and family time.

devjab 1y ago
I'd argue that it depends on your users. From a business perspective, it's a lot safer for us to release on fridays because failures would not affect a lot of people over the weekend. Of course I do live in a country where you'd have to agree to fix it over the weekend, and if you do, you'd be compensated with new days off + money.

tsimionescu 1y ago

Having literally no branches might work for tiny projects, but none of this is the case for any decently-sized software. If you want to release a piece of software to a customer who will be using it as-is for some time (which is one possible business model), then you need a version of your software where all features that the customer sees are working well. To do that, you need to fix even minor bugs in those features without adding any (visible) new features to the product. However, this doesn't scale. You can't pause all development of new features while someone is re-aligning a few UI elements and cleaning up error messages that were too confusing. So, you have to create a split in the software: one part is getting ready to ship, another is work in progress for future releases. Now, you can create this split using git branches, or using feature flags. So yes, trunk based development can work, you can absolutely build up the new experimental features into the software you're about to ship, but you'll have to hide them behind a feature flag that is disabled - a runtime branch. Or, you can have a release branch where only bug fixes are allowed, and submit major new work on the main branch. There are pros and cons to either solution, but whatever you do, you need stable vs unstable branches somewhere. And, of course, sometimes you'll have to release hotfixes, and there you won't get away without a true SCM branch, since you can't just give your customers your latest and greatest software just to patch a security issue in libcurl for a 2 year old release.

deleted 1y ago
[deleted]

beingfit 1y ago

> The disadvantage of feature branching is that it's very easy for management to cut costs on testing. Have to agree with this. In a large (lower than 2/3rd in the Fortune 500 list) company with cost cutting as a constant mantra, our ever shrinking team hasn’t had a testing/QA team for several years. We never got to automating a lot of tests either. The developers create something and test it manually as per their limited knowledge. Then it’s the end users who do the bulk of the testing.

ido 1y ago

> When we do trunk-based development, the WIP we commit gets used, before any actual user sees it, by our whole team. And of course internal teams love also doing QA on the side of their existing jobs ;) I think that’s fair enough to ask from developers and project/product managers but a lot of others on the team basically have to suffer lower productivity to test your code.