The Continuous Delivery Test

Extremely web centric list. Any other development (mobile, desktop, games, embedded, …) will find a lot of these steps very weird.

9. Does your Infrastructure as Code live alongside the service it hosts?<p>No, the IaC is configuration, and configuration should be separated from the application.<p>in organizations that implemented GitOps, the IaC files in git are not only a copy of the configuration, it is the source of truth from which the configuration is copied to the systems. Unless all the developers who can commit code should have permission to change production configuration, the IaC repo should be separated from the code repo.

&gt; 11. Do you include ticket IDs in your commits or branches?<p>This is one of the things that sound &#x27;good&#x27; on the surface and are totally worthless in practice (especially when practicing minimal commits).<p>In the wild this devolves into a meaningless umbrella issue (Deliver Feature Foo) or 1 liner issues that sometimes did not even match the pr contents.<p>Just use the commit message and in pr review enforce commit message norms.

&gt; 9. Does your Infrastructure as Code live alongside the service it hosts?<p>That means minor changes to some test infrastructure have to go through the strict review process, because the gitlab-ci.yaml is in the part of the main code. Last time this happened to me I found it annoying, and I don&#x27;t think the code quality guardians care about some CI config anyway.

7. 7! This is by far the one that resonates with me the most. But for some reasons SREs think the opposite is true: the longest it takes to get to prod, the better. What a pain.

This feels like yet more cargo-culting.<p>Even the first item on this list is hotly contested, with Facebook&#x2F;Microsoft&#x2F;Google and Co. using centralised mono-repos, google itself using a server model similar to Perforce called Piper.<p>To be clear here, I’m not saying they’re right, but with it feels un-scientific to make a blanket statement that they’re wrong.

I&#x27;d like to see a workflow that meets all the criteria. I was surprised to see the item about deploying directly from your own machine; that seems to contradict the other goals which point to automated pipelines that deploy on merge.