3 ms·

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 e

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.

cqqxo4zV46cp 3y ago
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.
- koolcode 3y ago
  > the usual pass-ag nerd habit of mistaking personal preference for absolute objective truth. Gospel
- SideburnsOfDoom 3y ago
  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".
master_crab 3y ago
This. Also, you rarely have a full idea how your downstream clients interact with the system that was changed.
- ehnto 3y ago
  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.
  - SideburnsOfDoom 3y ago
    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.
    - SideburnsOfDoom 3y ago
      > 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.

cqqxo4zV46cp 3y ago

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.

koolcode 3y ago
> the usual pass-ag nerd habit of mistaking personal preference for absolute objective truth. Gospel
SideburnsOfDoom 3y ago
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".

master_crab 3y ago

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

ehnto 3y ago
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.
- SideburnsOfDoom 3y ago
  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.
  - SideburnsOfDoom 3y ago
    > 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.