Making a Case for CI/AAD over CI/CD in DevOps

CI/CD has become a hot term in the tech industry, and one that more and more companies are looking for in Candidates for Their DevOps roles, their trying to fill.

With how much hype CI/CD has its easy for companies to think that’s the gold standard, but is it really?

To answer this, we need to look at what CI/CD is.

The CI in CI/CD stands for Continuous Integration and refers to the process of an automated set of steps such as build, and automated tests automatically getting kicked off or triggered based on some event such as a developer opening a pull request, or a pull request being approved and code trying to merge into a branch of other code.

The CD in CI/CD stands for Continuous Deployment and refers to the deployment of code to environments automatically without any manual intervention. Now you may be thinking to yourself “yeah that’s the goal.” But there is an inherent downside to Continuous Deployments. That’s the risk that our automated tests only account for things we thought of, not things we haven’t thought of.

Hearing this may make it sound like the most obvious point but it’s one that many overlook in their haste to automate everything in their efforts to implement CI/CD. For example, perhaps there’s some code checked in that contains a typo, that code manages to pass a code review, and unit tests are put in place, to test a new function in the code. The code passes unit test and enters the continuous Deployment pipeline and gets deployed to your companies’ customer facing site (aka production) automatically.

The code passed the unit tests, but what got missed was a small typo that didn’t affect the function of the site but rather what resources got loaded, and now when people are going to your site it looks completely different making visitors wonder if the site was hacked, or if the developers are incompetent to miss such a blatantly obvious change, and in both cases reducing customer confidence in your company, damaging your brand. This is where CI/AAD comes in.

CI/CD certainly has its place but it’s not a magic bullet. Continuous Deployments to the Dev environment so developers can quickly see their code change in action to make sure they think it’s ready for QA. In fact, there may be no better use case for CI/CD than this scenario.

This led me to think there must be a better way than CI/CD for production and even QA environments where continuous deployments may not be wanted. CI/AAD still uses Continuous Integration, but instead of Continuous Deployment has a subtle but distinct difference in that it uses Automated Approved Deployments.

What this means is the deployment process itself is still automated but doesn’t occur until an authorized person or persons click some sort of approval button. This ensures that there’s no accidental deploys as it gives the team a chance to review the code change in one environment before it goes out to another environment such as production. This also gives the team a chance to go in and see the site and do any manual testing to catch any blatant issues that we didn’t account for in our unit tests. This may sound as though it would prevent you from your goal of 20 deploys per day to production, but it really doesn't have to. In an agile developer shop, changes should be fairly small, making the testing that's needed by a QA team, minimal.

It may add a few minutes to the time it takes it to get to QA and ultimately to production but those precious couple minutes are worth every second spent, when compared against loss of brand reputation.

Like anything else, it comes down to using the right tool for the job. Thanks for reading.