3 ms·

Allowing direct push to master is fine so long as you 1) have a small team so it's not very congested 2) have a short enough build/test cycle that you can enfor

Allowing direct push to master is fine so long as you 1) have a small team so it's not very congested 2) have a short enough build/test cycle that you can enforce running tests locally. As soon as your test suite grows to the point that users aren't likely to run ALL tests before pushing new changes, you can't. Also, if you want to have code reviews at all, you want them pre-merge. If you have irreversible changes (For example: you have code that writes a serialized format and once you review the code that changes it, people have already used the code, even if only in testing/staging - but you now have data serialized in the bad wire format that you may need to be able to correct, and the correction code after review will need to be maintained forever unless you accept the loss of the data). I think: commit directly to master to scaffold and iterate quickly on a greenfield project with 1-3 devs. Then start doing feature branches and PR's to master.

Gareth321 5y ago
Exactly this. One particularly haughty CEO I worked for came to this exact same revelation. "But what about bugs?" "Just tell the developers not to add any bugs!" I'm not even kidding. That's what he said. Continuous release is fine for applications which aren't mission critical AND you have users who are accepting of an increase in bugs. Back in the real world, it's just not a good idea. We're all trying to calibrate the right balance between QA and output, and there are many ways to find the right balance. I remain unconvinced that "YOLO" is ever the right process.
- deleted 5y ago
  [deleted]
- teknopaul 5y ago
  Trunk dev and continuous releasing every push to trunk is not something I have heard suggested. If you want CD from some particular branch it would be silly to suggest the active dev branch. Trunk dev is about how and when new code is merged. It says nothing about when it is released. It's incorrect to think that any people doing trunk dev deploy from trunk willy nilly.
  - CRConrad 5y ago
    > Trunk dev and continuous releasing every push to trunk is not something I have heard suggested. Maybe not explicitly, but that's how it comes off. > Trunk dev is about how and when new code is merged. > It says nothing about when it is released. So why does the compound "CI/CD" term even exist? (IMO, it sucks; all it does is introduce the confusion you're deploring.) > It's incorrect to think that any people doing trunk dev deploy from trunk willy nilly. Blame, if not the people using the term "trunk", then the ones using "CI/CD", for this confusion.
teknopaul 5y ago
As soon as your test suite grows to the point that users aren't likely to run ALL tests before pushing new changes, you can't. Why? I have run trunk for years, naturally you don't tag and deploy to prod if tests fail. But the world keeps turning if trunk has a test fail. Or a build breakage. Or a code style breakage. You just fix it. On trunk, everyone can see it and anyone can fix it. Big fan on commit early.
- alkonaut 5y ago
  > the world keeps turning if trunk has a test fail. Or a build breakage. The world stops for the other developers that were unfortunate enough to pull/rebase their work when there was a build breakage. Having people shout “don’t pull, master is broken” is more overhead than is lost on PRs. A test fail isn’t as serious as no one is completely blocked, but a CI build that has 5 test failures can easily get another 5 before 3 of the first 5 are fixed. Before the end of day 1 you have a dozen failing tests of 3-4 different ages, some of which aren’t attributed to those who broke them. Finding who should stop what they are doing and fix the test is a job that needs to be done.
  - teknopaul 5y ago
    Not saying there is no cost but... You can happily pull master with a test fail. Everyone has immediate visibility. _Anyone_ can fix it: you don't have to find _who_ fixes it. That does presume you are OK with collective responsibility for the codebase, but I have never worked without that. If you live in that world, I feel bad for you son ;) Given collective responsibility : If the same issue is on a branch its still there, its hidden and lives longer. In my experience the _faster_ you find issues the cheaper they are to fix. If the commiter is not there, and the issue is on a branch, its the same concern when someone _else_ has to merge the branch to develop. Its just been sat there longer. It likely did not show up in CI tools so fast. You came across it out of context. If you insist one dev per branch and that dev merges, thats playing blame games. I don't find that helps team interactions. I find it better to write your code and your bugs together and fix them in plain sight. We all know breakage is inconvenient so we all try not to do it on branches or trunk.

Gareth321 5y ago

Exactly this. One particularly haughty CEO I worked for came to this exact same revelation. "But what about bugs?" "Just tell the developers not to add any bugs!" I'm not even kidding. That's what he said. Continuous release is fine for applications which aren't mission critical AND you have users who are accepting of an increase in bugs. Back in the real world, it's just not a good idea. We're all trying to calibrate the right balance between QA and output, and there are many ways to find the right balance. I remain unconvinced that "YOLO" is ever the right process.

deleted 5y ago
[deleted]
teknopaul 5y ago
Trunk dev and continuous releasing every push to trunk is not something I have heard suggested. If you want CD from some particular branch it would be silly to suggest the active dev branch. Trunk dev is about how and when new code is merged. It says nothing about when it is released. It's incorrect to think that any people doing trunk dev deploy from trunk willy nilly.
- CRConrad 5y ago
  > Trunk dev and continuous releasing every push to trunk is not something I have heard suggested. Maybe not explicitly, but that's how it comes off. > Trunk dev is about how and when new code is merged. > It says nothing about when it is released. So why does the compound "CI/CD" term even exist? (IMO, it sucks; all it does is introduce the confusion you're deploring.) > It's incorrect to think that any people doing trunk dev deploy from trunk willy nilly. Blame, if not the people using the term "trunk", then the ones using "CI/CD", for this confusion.

teknopaul 5y ago

As soon as your test suite grows to the point that users aren't likely to run ALL tests before pushing new changes, you can't. Why? I have run trunk for years, naturally you don't tag and deploy to prod if tests fail. But the world keeps turning if trunk has a test fail. Or a build breakage. Or a code style breakage. You just fix it. On trunk, everyone can see it and anyone can fix it. Big fan on commit early.

alkonaut 5y ago
> the world keeps turning if trunk has a test fail. Or a build breakage. The world stops for the other developers that were unfortunate enough to pull/rebase their work when there was a build breakage. Having people shout “don’t pull, master is broken” is more overhead than is lost on PRs. A test fail isn’t as serious as no one is completely blocked, but a CI build that has 5 test failures can easily get another 5 before 3 of the first 5 are fixed. Before the end of day 1 you have a dozen failing tests of 3-4 different ages, some of which aren’t attributed to those who broke them. Finding who should stop what they are doing and fix the test is a job that needs to be done.
- teknopaul 5y ago
  Not saying there is no cost but... You can happily pull master with a test fail. Everyone has immediate visibility. _Anyone_ can fix it: you don't have to find _who_ fixes it. That does presume you are OK with collective responsibility for the codebase, but I have never worked without that. If you live in that world, I feel bad for you son ;) Given collective responsibility : If the same issue is on a branch its still there, its hidden and lives longer. In my experience the _faster_ you find issues the cheaper they are to fix. If the commiter is not there, and the issue is on a branch, its the same concern when someone _else_ has to merge the branch to develop. Its just been sat there longer. It likely did not show up in CI tools so fast. You came across it out of context. If you insist one dev per branch and that dev merges, thats playing blame games. I don't find that helps team interactions. I find it better to write your code and your bugs together and fix them in plain sight. We all know breakage is inconvenient so we all try not to do it on branches or trunk.