I disagree with the POV of the article. That said, I do work at Spacelift[0], a specialized CI/CD for Infra as Code (so you can either take this with a grain of

I disagree with the POV of the article. That said, I do work at Spacelift[0], a specialized CI/CD for Infra as Code (so you can either take this with a grain of salt, or more trust, due to the increased exposure). > First, CI rarely knows what has changed, so everything needs to be rebuilt and retested. Yes, this is an issue with some CI/CD systems, an issue you can solve however. See our Push Policies[1] based on Open Policy Agent. Test-case caching is also sometimes available (available in i.e. Go). > Running tests pre-commit is one answer. Running tests locally for a quick feedback loop - sure, that's fairly mainstream though (something you can use our local preview[2] for as well in the case of IaC). Running tests locally before directly deploying to prod - that would be a compliance and security nightmare. The author presents what looks to me like a very "move fast, break things" attitude, that doesn't really work in a whole lot of cases. If your CI/CD is slowing you down, make it faster. Easier said than done, I know, but a lot of people don't even think about optimizing their CI/CD, which you often can do, by being smarter about what you run and/or parallelizing extensively and/or caching[3]. [0]:https://spacelift.io https://spacelift.io [1]:https://docs.spacelift.io/concepts/policy/git-push-policy https://docs.spacelift.io/concepts/policy/git-push-policy [2]:https://docs.spacelift.io/concepts/stack/stack-settings#enable-local-preview https://docs.spacelift.io/concepts/stack/stack-settings#enab... [3]:https://github.com/actions/cache https://github.com/actions/cache