4 ms·

This seems to be advocating the second workflow, i.e. pushing on a short lived branch then merging back in (their intermediate setup seems impractical technical

This seems to be advocating the second workflow, i.e. pushing on a short lived branch then merging back in (their intermediate setup seems impractical technically for most setups - how do you run standard tests without committing your code, unless you do everything locally?)

UK-Al05 5y ago
You answered the question. You run as many tests as you can locally. Sometimes you can't, and the build goes red and you fix it with another commit.
- pc86 5y ago
  Any workflow that involves breaking master for everyone seems broken at some level. Not saying I have a better solution off the top of my head, but "just fix it with another commit" is a big red flag IME.
  - UK-Al05 5y ago
    A broken build is meant to be everybody helps fix it situation.
    - pc86 5y ago
      I'm questioning the logic of having a workflow with a not-uncommon case of "this is on fire now everyone stop what they're doing and help me fix it" which is exactly what you'd have here.
  - mjr00 5y ago
    Even if you really wanted to have it be trunk-only, I don't know why you wouldn't make everyone push to a feature branch, then have automation for running tests and merging after they pass. Plus, where's the code review in this process? Even if your team is all amazing developers somehow, it's insecure to have a standard process where developers are pushing unreviewed code directly to production. Fundamentally this all seems like a misreading of trunk-based development, though. The whole idea was to get away from old Subversion-style branching, where there would be long-lived branches running for sometimes several month. If you were a company that moved from svn -> git, trunk-based development was a way of communicating that branches were cheap and disposable, and merging was quick and easy.
  - Jensson 5y ago
    Master isn't broken for everybody though? Its just broken for those projects whose tests are broken, everybody else can still work as normal. So unless you have a ton of dependencies you wont notice much breakages from other teams.
twic 5y ago
> This seems to be advocating the second workflow, i.e. pushing on a short lived branch then merging back in No, in trunk-based development, you push to the trunk, aka master. The difference is perhaps not that big; with TBD, you have a branch, but only on your machine, which you merge to master before pushing, whereas with the second workflow, you push your master, then merge somehow. > their intermediate setup seems impractical technically for most setups - how do you run standard tests without committing your code, unless you do everything locally? I don't understand this. Of course you can and should run all tests locally.
- sparsely 5y ago
  > No, in trunk-based development, you push to the trunk, aka master. If you follow the ops link there are multiple diagrams where that is not the case.
whynotmaybe 5y ago
One of the premises is that the minimum level of competence of the team should be above average, which is not feasible everywhere. And "The short-lived feature branch should only last a day or two and never diverge from the trunk enough so that a merge back is problematic. After the seal of approval from code reviewers and CI daemons, it should be merged back into the trunk. It should be deleted, as proof of convergence. The developer in question may then go ahead and make the next short-lived feature branch for the next story/task they’re doing" https://trunkbaseddevelopment.com/youre-doing-it-wrong/#duration-of-short-lived-feature-branches https://trunkbaseddevelopment.com/youre-doing-it-wrong/#dura...
jeffbee 5y ago
This is a very git-centric view. There are other source code management systems.

UK-Al05 5y ago

You answered the question. You run as many tests as you can locally. Sometimes you can't, and the build goes red and you fix it with another commit.

pc86 5y ago
Any workflow that involves breaking master for everyone seems broken at some level. Not saying I have a better solution off the top of my head, but "just fix it with another commit" is a big red flag IME.
- UK-Al05 5y ago
  A broken build is meant to be everybody helps fix it situation.
  - pc86 5y ago
    I'm questioning the logic of having a workflow with a not-uncommon case of "this is on fire now everyone stop what they're doing and help me fix it" which is exactly what you'd have here.
- mjr00 5y ago
  Even if you really wanted to have it be trunk-only, I don't know why you wouldn't make everyone push to a feature branch, then have automation for running tests and merging after they pass. Plus, where's the code review in this process? Even if your team is all amazing developers somehow, it's insecure to have a standard process where developers are pushing unreviewed code directly to production. Fundamentally this all seems like a misreading of trunk-based development, though. The whole idea was to get away from old Subversion-style branching, where there would be long-lived branches running for sometimes several month. If you were a company that moved from svn -> git, trunk-based development was a way of communicating that branches were cheap and disposable, and merging was quick and easy.
- Jensson 5y ago
  Master isn't broken for everybody though? Its just broken for those projects whose tests are broken, everybody else can still work as normal. So unless you have a ton of dependencies you wont notice much breakages from other teams.

twic 5y ago

> This seems to be advocating the second workflow, i.e. pushing on a short lived branch then merging back in No, in trunk-based development, you push to the trunk, aka master. The difference is perhaps not that big; with TBD, you have a branch, but only on your machine, which you merge to master before pushing, whereas with the second workflow, you push your master, then merge somehow. > their intermediate setup seems impractical technically for most setups - how do you run standard tests without committing your code, unless you do everything locally? I don't understand this. Of course you can and should run all tests locally.

sparsely 5y ago
> No, in trunk-based development, you push to the trunk, aka master. If you follow the ops link there are multiple diagrams where that is not the case.

whynotmaybe 5y ago

One of the premises is that the minimum level of competence of the team should be above average, which is not feasible everywhere. And "The short-lived feature branch should only last a day or two and never diverge from the trunk enough so that a merge back is problematic. After the seal of approval from code reviewers and CI daemons, it should be merged back into the trunk. It should be deleted, as proof of convergence. The developer in question may then go ahead and make the next short-lived feature branch for the next story/task they’re doing" https://trunkbaseddevelopment.com/youre-doing-it-wrong/#duration-of-short-lived-feature-branches https://trunkbaseddevelopment.com/youre-doing-it-wrong/#dura...

jeffbee 5y ago

This is a very git-centric view. There are other source code management systems.