Assuming a dev is committing (ball park) 4 times per day, that's in the region of $55k/year per developer, or $16.5M/year all in. Thats not cheap...

I would not assume that 300 developers are all committing 4 times a day. That seems very high.

And there you have it...$60 per commit means slowing down your commit velocity! Which means its longer before changes get tested or reviewed or deployed.

The cost (money and more importantly time) of running tests fundamentally changes the development process.

More commits are not better.

Unless you are a PHP developer

4 commits per day per developer is exceptionally high, unless these are tiny, tiny changes.

I'm a very productive engineer on my team and I average less than 1 commit per day.

You only need to run CI on Production, and you can squash commits. Generally a release is once per week, and at Oktas level you have a release engineer.

300 developers' work being crammed together into a weekly release without having their contributions pass CI first sounds absolutely hellish for whatever poor bastard has to track down who broke the build.

There's tooling like bors that will rollup commits together and run CI on them before merging to master. If it fails then the commits will be retried individually.

I suppose so, but that cuts down on the number of CI runs when merging to master because the vast majority of commits being merged to master don't fail the build.

In a typical bors workflow, that holds, because you do a CI run before attempting to merge, so commits don't break the build except in the rare case that two commits that are individually okay combine in a way that breaks.

If you get rid of the individual run before merging, your combined runs will hardly ever pass, so it won't cut down on the number of runs.

Yes, I suppose I could be taking the anecdote too literally. It's much more likely they are only running all test on push to main / against pull requests / on code review.