There’s actually another maturity level:

3. The processes are automated, and high enough quality that we can be confident that clicking the "go" button" will either result in the build/test/deploy pipeline halting due to a problem, or a good release going to production. But we still prefer not to release on Friday, because no CICD methodology is perfect.

There’s another maturity level: blah blah blah, but our CICD setup and overall code quality has long proven itself to be of such quality that we as a team / organisation have opted to assume this risk.

My real point is that, at a point, reasonable people can disagree about this, and calling these “maturity levels” strays further from reality and closer to the usual pass-ag nerd habit of mistaking personal preference for absolute objective truth.

I've seen all three in use, and while agree that "maturity level" is not "absolute objective truth" - that's your overstated reading, but IMHO dismissing them as mere "personal preference" is also wrong in the other direction.

These are not personal - they are are the product of the interactions and agreements of a large number of co-operating people who look for ways to deal with release quality concerns with instruments that they are familiar with: signoffs, manual gates, controls; vs. automation and small batches.

Also dismissing them as "mere preference" implies that the outcomes will be broadly similar, in my experience this is not at all so. The industry has uncovered ways to proceed both fast and safely, but these are not widespread, partly because of the myopia that they are mere "preferences".

> the usual pass-ag nerd habit of mistaking personal preference for absolute objective truth.

Gospel

This. Also, you rarely have a full idea how your downstream clients interact with the system that was changed.

Same for me. I think we are all talking like we work on the exact same product. I work at an agency with many codebases, from different clients. Some we inherited that don't yet have good coverage, some with notoriously brittle third party integrations we can't truly test until it is in the live data environment, and some with clients who are very unresponsive and if we planned a Friday deploy the chances of a no-go because we couldn't get sign off or testers is pretty high. It is just all around easier to do midweek deploys in such an environment.

Do I envy the fully automated Friday deployment teams? Sure! But this is my commercial reality, and the pragmatic approach is to not deploy on Fridays.

It sounds like you're deep into scenario 2. The mention of "sign off or testers" is a dead giveaway. "testers" being people not automation. likewise "sign-off".

It also sounds like while you know that better exists, the "commercial reality" is "not on this project". I've been there too. I don't see this as being in conflict with what I said above.

> It sounds like you're deep into scenario 2.

Arrgh, I meant to say, "scenario 1" - the second scenario.

The first scenario is numbered 0, because it has zero process.

At my workplace we release small fixes on Fridays, but prefer to wait until Monday.

I don't see how we could trust ci/cd to catch all errors. Tests are great at detecting expected errors, but it's not possible for us to get 100% confidence.

We also need some sort of tradeoff. Creating a perfect system with few bugs take a lot of time and resources that a startup does not have. We accept that our releases may include bugs, because we can respond to angry customers quickly.

In our B2B industry, most of our customers sales happen during weekends. A bug has a much higher financial impact.