3 ms·

Also as far as I can tell OP’s recommendation is to break the mainline, then tell everyone it’s broken. > Instead, you frequently - at least once a day - put y

Also as far as I can tell OP’s recommendation is to break the mainline, then tell everyone it’s broken. > Instead, you frequently - at least once a day - put your code into a healthy state that passes tests and integrate it into the mainline IME that’s a perfect recipe for getting a mainline which never passes tests in any organisation of a non-trivial size, as soon as broken code has been pushed “giving a fuck” goes out the window and it takes weeks to recover (unless you just lock out everyone until shit’s been fixed). It’s already hard enough when you just have flaky code, or time-sensitive tests. If you want light reviews that’s a factor of development & review policy: let people self-review, make review scope clear, break up major changes into small tasks, …

xmcqdpt2 3y ago
Yes. I work on a monorepo with >1000 other devs, in every time zone. If we just broke mainline all the time, you'd get people merging broken code in Asia at the end of their work day and then we would have to revert it in NA. That would be a nightmare! Also I wish our CI took 10 min :( As of now it can take up to 90 minutes just to compile the codebase (although caching usually mean it's much faster than that.)
JenrHywy 3y ago
100% The author also seems to have missed that you can still use CI on feature branches. Merge `master` to your feature branch regular, run the CI. Sure, you're only integrating with other complete-ish work, but it gets you a long way without making a complete mess of things.
- clawlor 3y ago
  Some CI systems do this automatically for PR builds, e.g. TravisCI: > Rather than build the commits that have been pushed to the branch the pull request is from, we build the merge between the source branch and the upstream branch. https://docs.travis-ci.com/user/pull-requests/#how-pull-requests-are-built https://docs.travis-ci.com/user/pull-requests/#how-pull-requ...
twic 3y ago
No. You and those replying to you have completely misunderstood what the author wrote. My emphasis and a clarifying adverb: > As a team member, you don’t wait until you have finished a feature or story to integrate your code to the mainline. Instead, you frequently - at least once a day - put your code into a healthy state that passes tests and [then] integrate it into the mainline with everyone else’s current work. You get your local copy into a healthy state - build passing, tidied up, refactored - and then you push it upstream. The idea is precisely that you only push healthy code, and so never break mainline.
- masklinn 3y ago
  No, we understand perfectly well what the author wrote, but we’ve also worked with actual breathing humans rather than just spherical cows in vacuum, so we understand what will inevitably happen. This is about as realistic as telling devs not to push bugs. As soon as it gets in the way or there’s a boss breathing down the dev’s neck, anything which is not enforced is jettisoned.
  - twic 3y ago
    As far as i can tell from your comment ("as far as I can tell OP’s recommendation is to break the mainline"), you did not in fact understand what the author wrote. I've worked in trunk-based development shops for fifteen years. My colleagues have mostly been good, but certainly not superhuman. It works fine.
    - masklinn 3y ago
      > As far as i can tell from your comment you did not in fact understand what the author wrote. I like how you keep calling me a liar, it’s nice. > I've worked in trunk-based development shops for fifteen years. My colleagues have mostly been good, but certainly not superhuman. It works fine. The “E” in IME stands for Experience. I’ve worked in trunk-based development shops for years as well, it did not work fine, my comments are experience from seeing it break down as the number of devs increased, and the time wasted on mainline being broken kept ticking up. I’m happy for you if you never suffered from that, but I’m not going to argue for practices I’ve seen fail over and over.

xmcqdpt2 3y ago

Yes. I work on a monorepo with >1000 other devs, in every time zone. If we just broke mainline all the time, you'd get people merging broken code in Asia at the end of their work day and then we would have to revert it in NA. That would be a nightmare! Also I wish our CI took 10 min :( As of now it can take up to 90 minutes just to compile the codebase (although caching usually mean it's much faster than that.)

JenrHywy 3y ago

100% The author also seems to have missed that you can still use CI on feature branches. Merge `master` to your feature branch regular, run the CI. Sure, you're only integrating with other complete-ish work, but it gets you a long way without making a complete mess of things.

clawlor 3y ago
Some CI systems do this automatically for PR builds, e.g. TravisCI: > Rather than build the commits that have been pushed to the branch the pull request is from, we build the merge between the source branch and the upstream branch. https://docs.travis-ci.com/user/pull-requests/#how-pull-requests-are-built https://docs.travis-ci.com/user/pull-requests/#how-pull-requ...

twic 3y ago

No. You and those replying to you have completely misunderstood what the author wrote. My emphasis and a clarifying adverb: > As a team member, you don’t wait until you have finished a feature or story to integrate your code to the mainline. Instead, you frequently - at least once a day - put your code into a healthy state that passes tests and [then] integrate it into the mainline with everyone else’s current work. You get your local copy into a healthy state - build passing, tidied up, refactored - and then you push it upstream. The idea is precisely that you only push healthy code, and so never break mainline.

masklinn 3y ago
No, we understand perfectly well what the author wrote, but we’ve also worked with actual breathing humans rather than just spherical cows in vacuum, so we understand what will inevitably happen. This is about as realistic as telling devs not to push bugs. As soon as it gets in the way or there’s a boss breathing down the dev’s neck, anything which is not enforced is jettisoned.
- twic 3y ago
  As far as i can tell from your comment ("as far as I can tell OP’s recommendation is to break the mainline"), you did not in fact understand what the author wrote. I've worked in trunk-based development shops for fifteen years. My colleagues have mostly been good, but certainly not superhuman. It works fine.
  - masklinn 3y ago
    > As far as i can tell from your comment you did not in fact understand what the author wrote. I like how you keep calling me a liar, it’s nice. > I've worked in trunk-based development shops for fifteen years. My colleagues have mostly been good, but certainly not superhuman. It works fine. The “E” in IME stands for Experience. I’ve worked in trunk-based development shops for years as well, it did not work fine, my comments are experience from seeing it break down as the number of devs increased, and the time wasted on mainline being broken kept ticking up. I’m happy for you if you never suffered from that, but I’m not going to argue for practices I’ve seen fail over and over.