[alkonaut]

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]

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.

[teknopaul]

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]

> 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]

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]

> 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]

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.

[maccard]

> You can happily pull master with a test fail.

No, you can sometimes pull master with a test fail and knowing which tests are ok to fail is a skill in itself.

> That does presume you are OK with collective responsibility for the codebase

That only works on small projects and on "simpler" projects. On my last project with 100+ developers it was likely that a bunch of the failures could only be fixed by 1-2 people. Asking a tools programmer to fix a failing networking test, or a gameplay/network programmer to fix a material bug is a stupid waste lf time.

> If you insist one dev per branch and that dev merges, thats playing blame games

That's a strawman. Nobody is talking about one dev branch per person except you. There are other branching models (git flow, task branches or even feature branches) with well defined criteria for merging back to main available that allow for multiple team members and stability in main.

> We all know breakage is inconvenient so we all try not to do it on branches or trunk.

This is a very naive view and is the equivalent of "just make sure it works before you submit", and doesn't scale into even tens of developers working on a project in my experience.

[alkonaut]

> _Anyone_ can fix it: you don't have to find _who_ fixes it.

You can always "fix" the broken test by reverting the offending commit. But again, if someone has already committed on it, your history will be a mess. Actually fixing something takes developer B longer than it will take the dev who knows the context. So switching that responsibility - unless it's a typo - would be a massive waste of time. A nice "collective responsibility" perhaps, but a huge waste of time.

> 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 ;)

I do like having collective responsibility. But one of the most important responsibilities is having a clean history, a buildable branch to start from etc. "Fixing other people's typos" is a nice team excercise but it's pretty far down on my list of collective responsibilities.

> If the same issue is on a branch its still there, its hidden and lives longer.

Test failures when we did commit-to-master lived for days or weeks. Working with PR's doesn't slow me down at all. It's not like feature branches have to live for days. They can live 20 minutes. Of course, if you have a 1.5h CI and then wait for a code review, then it's going to be a few hours, but I wouldn't want to go back to churning on master with 30 others. I did that for 15 years before. With all kinds of teams.

> If you insist one dev per branch and that dev merges, thats playing blame games.

I don't care who merges. And whether the dev merges their own code or whether code review is required is a tangential question. The more important point is that the branch lets build+test be done while the dev does something else, and that the target branch is green in the meeantime. Again, if you can build+test in minutes, then perhaps doing master dev is fine because you can all just agree that "Team, let's try to compile and run all tests before committing to master ok thanks". But if you have a lenghty CI then what? Do you hope every dev runs the 3 hour test suite before committing? That also sounds like a massive waste of time where the developer could be working on the next thing already.