20 ms·

Trunk-Based Development: Game Changers

111 points by cpeterso 4y ago

morsch 4y ago
We have a main branch, and a develop branch. Feature branches are based on the main branch. When a developer is happy with their feature branch, they open a pull request to develop, which gets reviewed by another developer and, eventually, merged to develop. The code in develop gets deployed semi-hourly or on demand to a testing environment, where quality assurance takes on the feature branch. Eventually, when the testers are happy with the feature branch, it gets merged to the main branch. Main gets deployed to production daily, or on demand. There are no release branches or tags. Feature branches that take longer are periodically rebased on main (or main gets merged into the feature branch). On rare occasions, hotfix branches are merged directly to main (and immediately, possibly partially, deployed). That code lands in develop via an automatic merge process from main to develop. The weakness of the model would appear to be that testing practically never happens on the main code branch. I say practically, because we do have a staging environment that reflects the main branch code version, but it's almost unused. It just hasn't been an issue in a decade+ working this way with a team of 8-20 developers. Maybe it doesn't scale to much larger teams? Someone help me out, is there a name for this model? It doesn't appear to be gitflow, which IIUC periodically transforms (or merges) the entire develop branch into main branch (we never do this). But it also doesn't sound like it's trunk based development, which doesn't seem to have a develop branch, and also uses versioned releases. We can't be the only ones doing it this way?
- loupol 4y ago
  I've definitely seen the same model used. Small company also.
- civilized 4y ago
  What I don't understand about this model is 1. What is the relationship between the code in the main branch and the code in the develop branch? 2. What assurance does the testing on the develop branch provide that the feature branch is suitable to merge into the main branch? I mean, presumably you've got main and develop because they need to be different. But then, because they're different, you're never really testing the code that you actually deploy. Superficially, it seems both more complicated and less reliable than trunk-based development. What am I missing? Why would this way of working be helpful?
  - morsch 4y ago
    The develop branch is main + feature branches currently in qa. > But then, because they're different, you're never really testing the code that you actually deploy. That's true, and I alluded to it in my comment. It's conceivable that feature-1 and feature-2 are simultaneously in develop, feature-1 gets tested successfully and is merged into main; and then it turns out you needed feature-2 to actually fulfill all requirements. Seems like it'd happen all the time, but in practice, it just doesn't. Probably a combination of unit tests, backend code being written in a static language, and developers, qa, and pms using their head. > Why would this way of working be helpful? Having little experience with anything else, it's difficult for me to say. It seems quite flexible: we release individual features or, sometimes, related features that are compounded into a feature branch. Main essentially never breaks, and it's nice that you can essentially deploy it whenever you want without explicitly packaging a version and testing it. That seems to be the idea behind trunk-based development, too. But then, develop does break occasionally (i.e. a bug was discovered during testing), and it's nice that this is allowed, as well. Having to revert a feature branch from trunk because a bug was discovered sounds terrible, and also what if you released trunk in the meantime? It sounds to me like it could only work if the feature branches itself are the subject of QA (and then you have a similar problem as testing our develop branch).
    - civilized 4y ago
      Thanks, this mostly makes sense now. > The develop branch is main + feature branches currently in qa. Is any work done to ensure this, or is it just a byproduct of the way of working? I'm struggling to understand how it would just happen automatically.
      - morsch 4y ago
        Well, it's manual in that when a developer thinks they're done, they open a pull request from feature branch to develop. That's where code review takes place, and as such it's a core part of the workflow. Failing qa might mean additional commits on the feature branch and another pull request to develop. (Develop should really be called testing or qa; historical reasons.)
- kkapelon 4y ago
  Gitflow and TBD are just two of the many possible ways to use Git. Several companies (such as yours) use other systems that have no name. And that is fine. We don't need to name every possible variation of a Git model.
  - morsch 4y ago
    If it doesn't have a name, I might give it one and document it more formally than in a hacker news comment. I was under the impression that most teams implement one of a handful of standard models. But it's possible that you're right that there's more variation to it than I thought.
- dezgeg 4y ago
  Maybe I misunderstood your description, but does 'develop' not ever merge to 'main' directly? Your description sounded like QA could for example test 'develop' which is main + featureA + featureB, give that a green light, and then have new main be main + featureA (which has been never tested). That does sound bit dangerous. (As an embedded developer, it would be bliss to experience 'develop gets deployed semi-hourly'...)
  - morsch 4y ago
    No, develop never gets merged to main. In fact, I've been meaning to add a dummy commit to develop and a commit hook that declines it being merged to main, to ensure nobody merges it by accident. One of these days... You've identified what I'd call the main weakness, but in practice it hasn't been an issue. I've discussed it in a bit more detail in a sibling post. Ymmv.
- TeeWEE 4y ago
  We use a similar model, but only one "main" branch, which get a tag when released. I would call it trunk based development, since feature branches are short lived.. Most MR are just 1 or 2 commits. Just part of our review process.
  - morsch 4y ago
    How often do you release? Is there any manual qa (as opposed to unit or integrating tests)? Does a bug in one feature block the release of others (because it means main has a bug)?
- deleted 4y ago
  [deleted]
margorczynski 4y ago
In regards to the subject I think it is also important for the developers to understand and agree upon what the mainline (master/main/etc.) branch represents. For me it should contain only commits/changes which result in the new HEAD properly working and having a bug fixed and/or feature added. So the feature/bug/etc. branches can contain multiple commits which are helpful for the developer(s) that's working on it but it all should be squashed into a single one during merging into master. In short the history noise in master should be kept in check and reduced as much as possible which makes e.g. bisect easier as we don't take into account pointless commits and the history is cleaner. Problem is many think "more is better" and they end up with branches that are much more complicated to work with and reason about.
TeeWEE 4y ago
Trunk based development is a marketing name.. Frequent releases of a main branch to which developers push code (either via other branches, mr's) or direct commits... Thats what it is.. Even if you create a release branch on every release... A tag would also do.. But a tag and a branch are technically quite similar in git... Its mostly fluff Deploy often, dont have long lived branches. Have your main branch in a deployable state 90% of the time... Hoora youre there
- bob1029 4y ago
  > Have your main branch in a deployable state 90% of the time With a little bit of extra process (i.e. enforce that unit tests succeed on proposed merge items), you can get very close to 100% for most projects.
  - cassianoleal 4y ago
    Agree. Aim for 100%. Have a process in place for when it breaks so it can be fixed immediately.
ilyt 4y ago
At that I'm kinda waiting for someone to advertise "just putting each release in tarball with date in name" as the new hot in source control. Hell, let's go back to CVS while we're at it
jedberg 4y ago
It's really important to point out that Google's monorepo works in large part because they have spent 100s of engineering years on their build and deployment tools. It would be very hard for a large company to adopt their monorepo because you'd have to replicate their tools. Just in case anyone was thinking of just copying Google...
fwlr 4y ago
Trunk-based development reminds me of Agile Development: the drawbacks mostly accrue to the developers while the benefits mostly accrue to the managers.
- fallbackboy 4y ago
  What exactly is a drawback of Trunk-based development for developers?
  - convolvatron 4y ago
    not allowed to integrate with other people's work in progress without a trip through main. also dont know how you are supposed to put out maintenance releases.
    - atrandom 4y ago
      Branch from a tag, make or cherry pick the fix, tag, deploy.
    - fallbackboy 4y ago
      I don't think it's a great idea to integrate with other work in progress, living on another feature branch. As far as maintenance releases go, strategies for resolving this are well documented here https://trunkbaseddevelopment.com/branch-for-release/#fix-production-bugs-on-trunk https://trunkbaseddevelopment.com/branch-for-release/#fix-pr....
    - stetrain 4y ago
      You can follow the core of trunk based and still work together with another person on a shared feature branch if that is needed. I have found benefits though to structuring your WIP in a way that it can be merged into the trunk with minimal risk of breaking existing stuff. This is a mindset change around favoring adding new modules / components / endpoints without clobbering working code, especially for larger projects where the code is going to come in over the course of many releases. Maintenance releases are done by going back to the tag or branch for your current prod release, making a new release branch from it, and pulling in whichever commits are needed.
convolvatron 4y ago
I know its hardly fashionable...but what's really wrong with release integration branches?
- jchw 4y ago
  Above all, it's just a pain in the ass. It's more something I'd do because I have to.
- TheGeminon 4y ago
  I’ve personally never worked on one much, but you have to keep (at least) two branches active for a release. Main development would happen on a shared feature branch (to be larger merged), but you also need to keep master/main updated with bug fixes and other changes that aren’t release gated. More around versioning itself, but having a single big merge is a single high risk point. Releasing everything all at once is more likely to have larger and more severe bugs than many small releases, even if you gate the deployed releases behind feature flags.
- Ao7bei3s 4y ago
  In my experience, working primarily based on integration branches, as opposed to working on master and cherry-picking back into integration branches, provides some short term benefits but is net negative in the long term. 1. People stop caring about master. Then master breaks and nobody fixes it. This is a problem if not _everyone_ is on the integration branch, e.g. if there is a single small team working on a feature for the next+1 release that needs master: they can't fix all the breakage from all the other teams, and they can't get the other teams invested in not breaking master. This ruins that teams productivity, which makes development of larger scale features much more costly. Even if no team needs master, leaving master broken and coming back to it later makes those fixes more costly. 2. Regressions: people mark bugs closed as soon as it is fixed in the integration branch. Then the fix never makes it into master, and you get regressions on the next+1 release. Automatic forward merge (always immediately and automatically merge release/n to release/n+1 [...] to master) as supported by e.g. Bitbucket can help with this, at the cost of the occasional merge conflict(s) and less control in case some fixes actually should not go into a specific intermediate release.
- 4y ago
4pkjai 4y ago
I love trunk based development, but hardly ever get to do it because other developers don’t like it.
- deleted 4y ago
  [deleted]
- mailund 4y ago
  I have the same experience! Trying to introduce the teams I've worked on to TBD and frequent releases, but they don't see any issue with long lived branches and infrequent releases
  - onion2k 4y ago
    they don't see any issue with long lived branches Probably because for most teams there isn't an issue. You only start to see the problems long term branches cause when you have multiple long-term branches in a single repo, and that only happens when your team is sufficiently big to be working on several big things at once or when your product is big enough to use a monorepo where devs on different teams work on the same parts at the same time. If you're Google or Meta these are very obvious problems that you'll see causing issues regularly. If you're a team of 6 in a corporation or a SaaS then you'll be able to work on a branch for weeks and still be able to merge it without any big problems. This is my main issue with TBD actually - it's a solution to a problem that few teams actually have. Throwing away a working process like gitflow when you won't see any real benefit doesn't seem like a great idea.
    - ilyt 4y ago
      Gitflow is also solution to problem few teams actually have. It is made to have few long term release versions, say you're making a database and need to support customer being major version or two behind for some years. But if you are just making app for a client you really need just "this is released as stable and running in prod" and some flavours of dev/test environment and that doesn't need much of model to work at all, just prod/test branch with features never landing directly on prod is good enough.
dgb23 4y ago
> It is important to note that today’s CR-delimited text file systems are blunt instruments compared to the fine-grained directed graphs with fidelity down to class/method history of each of those. It was more like a multidimensional database with cross-cutting tags representing HEAD, or someone else’s important combination of those three. It was omnipresent too - a decision made to move HEAD was instantly available without ‘update’ action to teammates These stories about Smalltalk and Lisp (machines) sometimes read as if they came from a forgotten, ancient civilization that was way more advanced than ours. When does the renaissance come?
- igouy 4y ago
  Been and gone ;-)
- malkia 4y ago
  When you can sanely merge changes.
- paul_h 4y ago
  Author checking in. I wrote on Smalltalk's ENVY too - https://paulhammant.com/2017/09/01/smalltalk-envy https://paulhammant.com/2017/09/01/smalltalk-envy. Though I've used it myself, I've paired with many that have.
  - igouy 4y ago
    There's an actual book — "Mastering ENVY/Developer" https://www.google.com/books/edition/Mastering_ENVY_Developer/ld6E19QIMo4C?hl=en&gbpv=1 https://www.google.com/books/edition/Mastering_ENVY_Develope... The fun thing is the way people could subvert and ignore the recommended development process because it seemed inconvenient to them.
- bhaak 4y ago
  It might be there already for distributed version control systems. https://pijul.org/ https://pijul.org/ I always wondered if git would have been as popular if it wouldn't have come from Linus.
- 4y ago
bjackman 4y ago
I think it's interesting to note that Google's "default" model now (what's recommend to incoming engineers) is the fully trunk-based monorepo, in a Perforce clone called Piper... But with a Mercurial based interface for actual development. In your individual checkout you can have arbitrary branching structures, then it just gets squashed down to a linear model when you submit to the monorepo. It's a bit annoying from a technical POV that there are two separate VCS, but the conceptual model works well IMO.
- flurdy 4y ago
  Reminds me of a friend wondering how he could keep local wip changes without polluting his git repo, or accidentally push WIPs to his colleagues. I suggested adding a personal Mercurial repo to the same folder. I think he was happy with that. Personally I often have lots of messy WIPs in temporary local git branches. With some rebase, squash and occasional reflog to keep main tidy.
- xen0 4y ago
  Quite a lot of people don't bother with the Mercurial layer, and it barely got a mention at my orientation three years ago.
agentjj 4y ago
It's rather funny. "Trunk-based development" is essentially counter-marketing to Gitflow. Before Gitflow, trunk-based development was so routine it didn't need a proper name or website. Gitflow has the "interesting" properties of being more complex than release-ready trunk-based setups, while (in most contexts) decreasing quality, and delivery speed. Unfortunately, Gitflow is very appealing to mediocre managers who want to point to a website and some pretty pictures and say "we do that" (thus, alleviating themselves of any actual engineering or contextual thinking). So the counter-marketing is helpful, but it feels rather ridiculous how the software world is so susceptible to these trends. It reminds me of the Alan Kay quote, "programming is a pop culture."
- kkapelon 4y ago
  Gitflow is very appealing to people that have multiple versions of the same thing in production. I would even consider it essential in such cases. The typical example is a B2B company that maintains one prod deployment per customer and each customer wants a completely different release schedule There are also several people that don't really care about release speed
  - jeffbee 4y ago
    I don’t get it. Nothing about trunk-based prevents multiple live release branches. It’s the direction of development that changes. You never work on the release branch, but you do down-integrate relevant changes from trunk to release.
    - cassianoleal 4y ago
      This is one of the points where the dogma breaks down. If trunk has changed substantially from the release branch where the patch is required, you can't cherry-pick and you need to work on the branch.
      - jeffbee 4y ago
        I of course cannot support dogma when it comes to software development. Pragmatism carries the day every time. But rare cases where a fix from head has to be edited to apply on a release branch does not invalidate the other advantages of trunk-based development, and there are ways to avoid the need to do such edits, including making sure that the pace of retirement of old releases is consistent with the pace of development on mainline.
IshKebab 4y ago
This could really do with defining what trunk based development is! Edit: I read the first hit from CircleCI and I am none the wiser. The article seems to suggest it could be any of these things: * Having a main (`master`) branch. But literally everyone except maybe Linux developers does this. * Not using branches? Which sounds awful. * Pushing directly to `master` and then running CI/CD! This is insane; does anyone really do this? So what is it exactly? Linear history?
- charcircuit 4y ago
  The article linked is a site all about trunked based development. >So what is it exactly? Linear history? The essence is that changes developers make are included into the trunk (main / master branch) as fast as possible. Developers shouldn't be branching off and spending a bunch of time making commits without them being added to to the main branch. You can run CI/CD on the commits developers want to get rebased onto the trunk.
- MiyamotoAkira 4y ago
  Point two: Alternatives to source control branches are dark launches, branch by abstraction and feature flags. Point three: The best results that I have had on developing systems were doing exactly that. You need more discipline (like make sure that you run test and linters locally), but my experience is that makes the whole process easier. CI is continuous integration, there is nothing continuous to coding on your branch and merging after a few days.
  - IshKebab 4y ago
    > You need more discipline (like make sure that you run test and linters locally) That sounds error prone. Wouldn't it make more sense to have an automated system to run tests and linters for you...? > but my experience is that makes the whole process easier. Sounds like you would just have people breaking `master` constantly to me. And how do you do code review? Or don't you? > there is nothing continuous to coding on your branch and merging after a few days. Yeah I guess the meaning has changed a little (or maybe standards have changed). These days CI basically means automatically testing every commit.

111 points by cpeterso 4y ago

We have a main branch, and a develop branch. Feature branches are based on the main branch. When a developer is happy with their feature branch, they open a pull request to develop, which gets reviewed by another developer and, eventually, merged to develop. The code in develop gets deployed semi-hourly or on demand to a testing environment, where quality assurance takes on the feature branch. Eventually, when the testers are happy with the feature branch, it gets merged to the main branch. Main gets deployed to production daily, or on demand. There are no release branches or tags. Feature branches that take longer are periodically rebased on main (or main gets merged into the feature branch). On rare occasions, hotfix branches are merged directly to main (and immediately, possibly partially, deployed). That code lands in develop via an automatic merge process from main to develop. The weakness of the model would appear to be that testing practically never happens on the main code branch. I say practically, because we do have a staging environment that reflects the main branch code version, but it's almost unused. It just hasn't been an issue in a decade+ working this way with a team of 8-20 developers. Maybe it doesn't scale to much larger teams? Someone help me out, is there a name for this model? It doesn't appear to be gitflow, which IIUC periodically transforms (or merges) the entire develop branch into main branch (we never do this). But it also doesn't sound like it's trunk based development, which doesn't seem to have a develop branch, and also uses versioned releases. We can't be the only ones doing it this way?

loupol 4y ago
I've definitely seen the same model used. Small company also.
civilized 4y ago
What I don't understand about this model is 1. What is the relationship between the code in the main branch and the code in the develop branch? 2. What assurance does the testing on the develop branch provide that the feature branch is suitable to merge into the main branch? I mean, presumably you've got main and develop because they need to be different. But then, because they're different, you're never really testing the code that you actually deploy. Superficially, it seems both more complicated and less reliable than trunk-based development. What am I missing? Why would this way of working be helpful?
- morsch 4y ago
  The develop branch is main + feature branches currently in qa. > But then, because they're different, you're never really testing the code that you actually deploy. That's true, and I alluded to it in my comment. It's conceivable that feature-1 and feature-2 are simultaneously in develop, feature-1 gets tested successfully and is merged into main; and then it turns out you needed feature-2 to actually fulfill all requirements. Seems like it'd happen all the time, but in practice, it just doesn't. Probably a combination of unit tests, backend code being written in a static language, and developers, qa, and pms using their head. > Why would this way of working be helpful? Having little experience with anything else, it's difficult for me to say. It seems quite flexible: we release individual features or, sometimes, related features that are compounded into a feature branch. Main essentially never breaks, and it's nice that you can essentially deploy it whenever you want without explicitly packaging a version and testing it. That seems to be the idea behind trunk-based development, too. But then, develop does break occasionally (i.e. a bug was discovered during testing), and it's nice that this is allowed, as well. Having to revert a feature branch from trunk because a bug was discovered sounds terrible, and also what if you released trunk in the meantime? It sounds to me like it could only work if the feature branches itself are the subject of QA (and then you have a similar problem as testing our develop branch).
  - civilized 4y ago
    Thanks, this mostly makes sense now. > The develop branch is main + feature branches currently in qa. Is any work done to ensure this, or is it just a byproduct of the way of working? I'm struggling to understand how it would just happen automatically.
    - morsch 4y ago
      Well, it's manual in that when a developer thinks they're done, they open a pull request from feature branch to develop. That's where code review takes place, and as such it's a core part of the workflow. Failing qa might mean additional commits on the feature branch and another pull request to develop. (Develop should really be called testing or qa; historical reasons.)
kkapelon 4y ago
Gitflow and TBD are just two of the many possible ways to use Git. Several companies (such as yours) use other systems that have no name. And that is fine. We don't need to name every possible variation of a Git model.
- morsch 4y ago
  If it doesn't have a name, I might give it one and document it more formally than in a hacker news comment. I was under the impression that most teams implement one of a handful of standard models. But it's possible that you're right that there's more variation to it than I thought.
dezgeg 4y ago
Maybe I misunderstood your description, but does 'develop' not ever merge to 'main' directly? Your description sounded like QA could for example test 'develop' which is main + featureA + featureB, give that a green light, and then have new main be main + featureA (which has been never tested). That does sound bit dangerous. (As an embedded developer, it would be bliss to experience 'develop gets deployed semi-hourly'...)
- morsch 4y ago
  No, develop never gets merged to main. In fact, I've been meaning to add a dummy commit to develop and a commit hook that declines it being merged to main, to ensure nobody merges it by accident. One of these days... You've identified what I'd call the main weakness, but in practice it hasn't been an issue. I've discussed it in a bit more detail in a sibling post. Ymmv.
TeeWEE 4y ago
We use a similar model, but only one "main" branch, which get a tag when released. I would call it trunk based development, since feature branches are short lived.. Most MR are just 1 or 2 commits. Just part of our review process.
- morsch 4y ago
  How often do you release? Is there any manual qa (as opposed to unit or integrating tests)? Does a bug in one feature block the release of others (because it means main has a bug)?
deleted 4y ago
[deleted]

margorczynski 4y ago

In regards to the subject I think it is also important for the developers to understand and agree upon what the mainline (master/main/etc.) branch represents. For me it should contain only commits/changes which result in the new HEAD properly working and having a bug fixed and/or feature added. So the feature/bug/etc. branches can contain multiple commits which are helpful for the developer(s) that's working on it but it all should be squashed into a single one during merging into master. In short the history noise in master should be kept in check and reduced as much as possible which makes e.g. bisect easier as we don't take into account pointless commits and the history is cleaner. Problem is many think "more is better" and they end up with branches that are much more complicated to work with and reason about.

TeeWEE 4y ago

Trunk based development is a marketing name.. Frequent releases of a main branch to which developers push code (either via other branches, mr's) or direct commits... Thats what it is.. Even if you create a release branch on every release... A tag would also do.. But a tag and a branch are technically quite similar in git... Its mostly fluff Deploy often, dont have long lived branches. Have your main branch in a deployable state 90% of the time... Hoora youre there

bob1029 4y ago
> Have your main branch in a deployable state 90% of the time With a little bit of extra process (i.e. enforce that unit tests succeed on proposed merge items), you can get very close to 100% for most projects.
- cassianoleal 4y ago
  Agree. Aim for 100%. Have a process in place for when it breaks so it can be fixed immediately.

ilyt 4y ago

At that I'm kinda waiting for someone to advertise "just putting each release in tarball with date in name" as the new hot in source control. Hell, let's go back to CVS while we're at it

jedberg 4y ago

It's really important to point out that Google's monorepo works in large part because they have spent 100s of engineering years on their build and deployment tools. It would be very hard for a large company to adopt their monorepo because you'd have to replicate their tools. Just in case anyone was thinking of just copying Google...

fwlr 4y ago

Trunk-based development reminds me of Agile Development: the drawbacks mostly accrue to the developers while the benefits mostly accrue to the managers.

fallbackboy 4y ago
What exactly is a drawback of Trunk-based development for developers?
- convolvatron 4y ago
  not allowed to integrate with other people's work in progress without a trip through main. also dont know how you are supposed to put out maintenance releases.
  - atrandom 4y ago
    Branch from a tag, make or cherry pick the fix, tag, deploy.
  - fallbackboy 4y ago
    I don't think it's a great idea to integrate with other work in progress, living on another feature branch. As far as maintenance releases go, strategies for resolving this are well documented here https://trunkbaseddevelopment.com/branch-for-release/#fix-production-bugs-on-trunk https://trunkbaseddevelopment.com/branch-for-release/#fix-pr....
  - stetrain 4y ago
    You can follow the core of trunk based and still work together with another person on a shared feature branch if that is needed. I have found benefits though to structuring your WIP in a way that it can be merged into the trunk with minimal risk of breaking existing stuff. This is a mindset change around favoring adding new modules / components / endpoints without clobbering working code, especially for larger projects where the code is going to come in over the course of many releases. Maintenance releases are done by going back to the tag or branch for your current prod release, making a new release branch from it, and pulling in whichever commits are needed.

convolvatron 4y ago

I know its hardly fashionable...but what's really wrong with release integration branches?

jchw 4y ago
Above all, it's just a pain in the ass. It's more something I'd do because I have to.
TheGeminon 4y ago
I’ve personally never worked on one much, but you have to keep (at least) two branches active for a release. Main development would happen on a shared feature branch (to be larger merged), but you also need to keep master/main updated with bug fixes and other changes that aren’t release gated. More around versioning itself, but having a single big merge is a single high risk point. Releasing everything all at once is more likely to have larger and more severe bugs than many small releases, even if you gate the deployed releases behind feature flags.
Ao7bei3s 4y ago
In my experience, working primarily based on integration branches, as opposed to working on master and cherry-picking back into integration branches, provides some short term benefits but is net negative in the long term. 1. People stop caring about master. Then master breaks and nobody fixes it. This is a problem if not _everyone_ is on the integration branch, e.g. if there is a single small team working on a feature for the next+1 release that needs master: they can't fix all the breakage from all the other teams, and they can't get the other teams invested in not breaking master. This ruins that teams productivity, which makes development of larger scale features much more costly. Even if no team needs master, leaving master broken and coming back to it later makes those fixes more costly. 2. Regressions: people mark bugs closed as soon as it is fixed in the integration branch. Then the fix never makes it into master, and you get regressions on the next+1 release. Automatic forward merge (always immediately and automatically merge release/n to release/n+1 [...] to master) as supported by e.g. Bitbucket can help with this, at the cost of the occasional merge conflict(s) and less control in case some fixes actually should not go into a specific intermediate release.
4y ago

4pkjai 4y ago

I love trunk based development, but hardly ever get to do it because other developers don’t like it.

deleted 4y ago
[deleted]
mailund 4y ago
I have the same experience! Trying to introduce the teams I've worked on to TBD and frequent releases, but they don't see any issue with long lived branches and infrequent releases
- onion2k 4y ago
  they don't see any issue with long lived branches Probably because for most teams there isn't an issue. You only start to see the problems long term branches cause when you have multiple long-term branches in a single repo, and that only happens when your team is sufficiently big to be working on several big things at once or when your product is big enough to use a monorepo where devs on different teams work on the same parts at the same time. If you're Google or Meta these are very obvious problems that you'll see causing issues regularly. If you're a team of 6 in a corporation or a SaaS then you'll be able to work on a branch for weeks and still be able to merge it without any big problems. This is my main issue with TBD actually - it's a solution to a problem that few teams actually have. Throwing away a working process like gitflow when you won't see any real benefit doesn't seem like a great idea.
  - ilyt 4y ago
    Gitflow is also solution to problem few teams actually have. It is made to have few long term release versions, say you're making a database and need to support customer being major version or two behind for some years. But if you are just making app for a client you really need just "this is released as stable and running in prod" and some flavours of dev/test environment and that doesn't need much of model to work at all, just prod/test branch with features never landing directly on prod is good enough.

dgb23 4y ago

> It is important to note that today’s CR-delimited text file systems are blunt instruments compared to the fine-grained directed graphs with fidelity down to class/method history of each of those. It was more like a multidimensional database with cross-cutting tags representing HEAD, or someone else’s important combination of those three. It was omnipresent too - a decision made to move HEAD was instantly available without ‘update’ action to teammates These stories about Smalltalk and Lisp (machines) sometimes read as if they came from a forgotten, ancient civilization that was way more advanced than ours. When does the renaissance come?

igouy 4y ago
Been and gone ;-)
malkia 4y ago
When you can sanely merge changes.
paul_h 4y ago
Author checking in. I wrote on Smalltalk's ENVY too - https://paulhammant.com/2017/09/01/smalltalk-envy https://paulhammant.com/2017/09/01/smalltalk-envy. Though I've used it myself, I've paired with many that have.
- igouy 4y ago
  There's an actual book — "Mastering ENVY/Developer" https://www.google.com/books/edition/Mastering_ENVY_Developer/ld6E19QIMo4C?hl=en&gbpv=1 https://www.google.com/books/edition/Mastering_ENVY_Develope... The fun thing is the way people could subvert and ignore the recommended development process because it seemed inconvenient to them.
bhaak 4y ago
It might be there already for distributed version control systems. https://pijul.org/ https://pijul.org/ I always wondered if git would have been as popular if it wouldn't have come from Linus.
4y ago

bjackman 4y ago

I think it's interesting to note that Google's "default" model now (what's recommend to incoming engineers) is the fully trunk-based monorepo, in a Perforce clone called Piper... But with a Mercurial based interface for actual development. In your individual checkout you can have arbitrary branching structures, then it just gets squashed down to a linear model when you submit to the monorepo. It's a bit annoying from a technical POV that there are two separate VCS, but the conceptual model works well IMO.

flurdy 4y ago
Reminds me of a friend wondering how he could keep local wip changes without polluting his git repo, or accidentally push WIPs to his colleagues. I suggested adding a personal Mercurial repo to the same folder. I think he was happy with that. Personally I often have lots of messy WIPs in temporary local git branches. With some rebase, squash and occasional reflog to keep main tidy.
xen0 4y ago
Quite a lot of people don't bother with the Mercurial layer, and it barely got a mention at my orientation three years ago.

agentjj 4y ago

It's rather funny. "Trunk-based development" is essentially counter-marketing to Gitflow. Before Gitflow, trunk-based development was so routine it didn't need a proper name or website. Gitflow has the "interesting" properties of being more complex than release-ready trunk-based setups, while (in most contexts) decreasing quality, and delivery speed. Unfortunately, Gitflow is very appealing to mediocre managers who want to point to a website and some pretty pictures and say "we do that" (thus, alleviating themselves of any actual engineering or contextual thinking). So the counter-marketing is helpful, but it feels rather ridiculous how the software world is so susceptible to these trends. It reminds me of the Alan Kay quote, "programming is a pop culture."

kkapelon 4y ago
Gitflow is very appealing to people that have multiple versions of the same thing in production. I would even consider it essential in such cases. The typical example is a B2B company that maintains one prod deployment per customer and each customer wants a completely different release schedule There are also several people that don't really care about release speed
- jeffbee 4y ago
  I don’t get it. Nothing about trunk-based prevents multiple live release branches. It’s the direction of development that changes. You never work on the release branch, but you do down-integrate relevant changes from trunk to release.
  - cassianoleal 4y ago
    This is one of the points where the dogma breaks down. If trunk has changed substantially from the release branch where the patch is required, you can't cherry-pick and you need to work on the branch.
    - jeffbee 4y ago
      I of course cannot support dogma when it comes to software development. Pragmatism carries the day every time. But rare cases where a fix from head has to be edited to apply on a release branch does not invalidate the other advantages of trunk-based development, and there are ways to avoid the need to do such edits, including making sure that the pace of retirement of old releases is consistent with the pace of development on mainline.

IshKebab 4y ago

This could really do with defining what trunk based development is! Edit: I read the first hit from CircleCI and I am none the wiser. The article seems to suggest it could be any of these things: * Having a main (`master`) branch. But literally everyone except maybe Linux developers does this. * Not using branches? Which sounds awful. * Pushing directly to `master` and then running CI/CD! This is insane; does anyone really do this? So what is it exactly? Linear history?

charcircuit 4y ago
The article linked is a site all about trunked based development. >So what is it exactly? Linear history? The essence is that changes developers make are included into the trunk (main / master branch) as fast as possible. Developers shouldn't be branching off and spending a bunch of time making commits without them being added to to the main branch. You can run CI/CD on the commits developers want to get rebased onto the trunk.
MiyamotoAkira 4y ago
Point two: Alternatives to source control branches are dark launches, branch by abstraction and feature flags. Point three: The best results that I have had on developing systems were doing exactly that. You need more discipline (like make sure that you run test and linters locally), but my experience is that makes the whole process easier. CI is continuous integration, there is nothing continuous to coding on your branch and merging after a few days.
- IshKebab 4y ago
  > You need more discipline (like make sure that you run test and linters locally) That sounds error prone. Wouldn't it make more sense to have an automated system to run tests and linters for you...? > but my experience is that makes the whole process easier. Sounds like you would just have people breaking `master` constantly to me. And how do you do code review? Or don't you? > there is nothing continuous to coding on your branch and merging after a few days. Yeah I guess the meaning has changed a little (or maybe standards have changed). These days CI basically means automatically testing every commit.