You’re going to deploy 4 CI pipelines (so make sure you’re not manually putting together ci pipelines configs, use automation):
Pipeline 1: A conveyor belt of environments. All this pipeline does is spin up fresh environments then run a short automated smoke test. Hydrate the env with the most recent mask from prod. The trigger condition is there’s less than <Threshold> environments available. I did 8 on a whim and never saw a need to change it.
Pipeline 2: Normal garden variety CI pipeline triggered on merges to main. Output of this will be two artifacts persisted: a built package and your unit test evidence
Pipeline 3: Test your automated deployment by deploying the package build from #2 into the first of the queue of free envs from #1 trigger your end to end and integration and contract tests. Don’t run your security or operability tests here.
Pipeline 4: Async pipeline triggered on a 6hr schedule, do your long running stuff like fuzz testing here, your security tests etc. do these outside of the dev cycle.
Release candidates can only be signed after a successful run through 2, 3 & 4. That means prod deploys are on a predictable cadence which users and ops are usually appreciative of rather than we drop it in when it’s ready.
The DevEx is pretty sweet - you don’t see pipeline 1 or 4 in your build loop. Only the runtime of 3 would be comparable to the article - slightly faster than the article because no firecracker bringup overhead, no matter how small that is.