4 ms·

Emphasis on all :). Of course the CI should always run them, but that should normally be as a confirmation/safeguard. I've seen too many cases where the devs

Emphasis on all :). Of course the CI should always run them, but that should normally be as a confirmation/safeguard. I've seen too many cases where the devs wouldn't even run the code locally. They would push it and expect the CI to do all the work. That's how you get shitty CI that is always broken.

deleted 4y ago
[deleted]
thiht 4y ago
That’s why you use branches though. You can break the CI on your own branch as much as you want, it’s nobody’s business. But a broken CI on a dev branch MUST prevent merging to a release branch. If you allow devs to push directly on release branch, thus breaking the CI, you’re absolutely doing it wrong.
- cassianoleal 4y ago
  The TBD [0] crowd disagrees with you. I agree with you though. Not that I don't see the value proposed by TBD, but I think you can have >90% of said value and none of the downsides using a well thought out branching strategy. [0] Trunk-Based Development: https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/
  - smallnix 4y ago
    From the linked Website: > Depending on the team size, and the rate of commits, short-lived feature branches are used for code-review and build checking (CI). [...] Very small teams may commit direct to the trunk.
    - cassianoleal 4y ago
      Indeed. That seems to be a new-ish addition. I'm glad they now admit alternate approaches.
  - liuliu 4y ago
    TBD doesn't mean you have a red CI main branch. Of course it is always green on main. It means you have short lived feature branch and rely on runtime checks for feature gating. A broken main will halt TBD. You are mischaracterize what TBD is.
  - cntainer 4y ago
    I'm in the "continuously improve the team's process to best suit its needs" crowd. Sometimes TBD is the answer, sometimes you need something else. What I did notice is that, with time, mature teams end up simplifying processes in order to reduce friction and increase output.
- cntainer 4y ago
  Well, I believe "absolutely doing it wrong" is a bit strong-worded. Of course you can do it like you said but that means longer feedback loops in general. If the team wants to integrate more often and reduce feedback loops then that model evolves. I'll give you an example. In the team I mentioned in my top comment we were initially using a branching model with master, releases/, hotfixes/, dev, features/, which gradually evolved into master, dev, features/, which finally ended up as master, features/*. With the important mention that for small changes/fixes that needed to get deployed quickly nobody would bother with a branch they would just push to master. This allowed us multiple production deploys per day per developer with no risk. That's why I said I don't get the point of the article, you can absolutely get those short feedback loops and continuous integration if you want it, just need to setup the process that way.
  - thiht 4y ago
    > Of course you can do it like you said but that means longer feedback loops in general. If the team wants to integrate more often and reduce feedback loops then that model evolves. Longer feedback loops =/= long feedback loops. You can definitely wait 5 to 10 minutes if it means doing it right. > With the important mention that for small changes/fixes that needed to get deployed quickly nobody would bother with a branch they would just push to master. From my experience, the 1-2 lines fixes are the ones that benefit the most from automated CI because you’re doing it in a rush. In my team just last week a junior dev asked us to review their PR quickly because it was just 2 lines, and it didn’t even compile. We told them to be more careful in the future, but in the end it didn’t impact anything. It couldn’t possibly have impacted anything thanks to CI, it just makes it impossible to fuck up too recklessly.
Merad 4y ago
> I've seen too many cases where the devs wouldn't even run the code locally. Lazy devs are going to be lazy no matter what processes their team uses.
- webdog 4y ago
  From the perspective of the dev, if my local CI isn’t worth anything towards a merge and upstream CI is gospel why run locally? If I’m reasonably certain that the two jobs are duplicative in output it could be seen as wasted time, especially if I have a PM hounding for features. I don’t call that lazy, I call that a trade off. (coming from someone who is constantly running tests locally before pushing upstream)
  - Merad 4y ago
    Isn't that slower and less efficient? Usually the CI has to run a full build from scratch before it can run the tests, but locally for me it's going to be an incremental build that takes a second or two. I can also run the subset of tests that I know are affected by my changes to get fast and reasonably reliable feedback vs waiting for CI to run the whole test suite.

deleted 4y ago

[deleted]

thiht 4y ago

That’s why you use branches though. You can break the CI on your own branch as much as you want, it’s nobody’s business. But a broken CI on a dev branch MUST prevent merging to a release branch. If you allow devs to push directly on release branch, thus breaking the CI, you’re absolutely doing it wrong.

cassianoleal 4y ago
The TBD [0] crowd disagrees with you. I agree with you though. Not that I don't see the value proposed by TBD, but I think you can have >90% of said value and none of the downsides using a well thought out branching strategy. [0] Trunk-Based Development: https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/
- smallnix 4y ago
  From the linked Website: > Depending on the team size, and the rate of commits, short-lived feature branches are used for code-review and build checking (CI). [...] Very small teams may commit direct to the trunk.
  - cassianoleal 4y ago
    Indeed. That seems to be a new-ish addition. I'm glad they now admit alternate approaches.
- liuliu 4y ago
  TBD doesn't mean you have a red CI main branch. Of course it is always green on main. It means you have short lived feature branch and rely on runtime checks for feature gating. A broken main will halt TBD. You are mischaracterize what TBD is.
- cntainer 4y ago
  I'm in the "continuously improve the team's process to best suit its needs" crowd. Sometimes TBD is the answer, sometimes you need something else. What I did notice is that, with time, mature teams end up simplifying processes in order to reduce friction and increase output.
cntainer 4y ago
Well, I believe "absolutely doing it wrong" is a bit strong-worded. Of course you can do it like you said but that means longer feedback loops in general. If the team wants to integrate more often and reduce feedback loops then that model evolves. I'll give you an example. In the team I mentioned in my top comment we were initially using a branching model with master, releases/, hotfixes/, dev, features/, which gradually evolved into master, dev, features/, which finally ended up as master, features/*. With the important mention that for small changes/fixes that needed to get deployed quickly nobody would bother with a branch they would just push to master. This allowed us multiple production deploys per day per developer with no risk. That's why I said I don't get the point of the article, you can absolutely get those short feedback loops and continuous integration if you want it, just need to setup the process that way.
- thiht 4y ago
  > Of course you can do it like you said but that means longer feedback loops in general. If the team wants to integrate more often and reduce feedback loops then that model evolves. Longer feedback loops =/= long feedback loops. You can definitely wait 5 to 10 minutes if it means doing it right. > With the important mention that for small changes/fixes that needed to get deployed quickly nobody would bother with a branch they would just push to master. From my experience, the 1-2 lines fixes are the ones that benefit the most from automated CI because you’re doing it in a rush. In my team just last week a junior dev asked us to review their PR quickly because it was just 2 lines, and it didn’t even compile. We told them to be more careful in the future, but in the end it didn’t impact anything. It couldn’t possibly have impacted anything thanks to CI, it just makes it impossible to fuck up too recklessly.

Merad 4y ago

> I've seen too many cases where the devs wouldn't even run the code locally. Lazy devs are going to be lazy no matter what processes their team uses.

webdog 4y ago
From the perspective of the dev, if my local CI isn’t worth anything towards a merge and upstream CI is gospel why run locally? If I’m reasonably certain that the two jobs are duplicative in output it could be seen as wasted time, especially if I have a PM hounding for features. I don’t call that lazy, I call that a trade off. (coming from someone who is constantly running tests locally before pushing upstream)
- Merad 4y ago
  Isn't that slower and less efficient? Usually the CI has to run a full build from scratch before it can run the tests, but locally for me it's going to be an incremental build that takes a second or two. I can also run the subset of tests that I know are affected by my changes to get fast and reasonably reliable feedback vs waiting for CI to run the whole test suite.