5 Minute DevOps: CD is Pointless

I tweeted this recently about continuous delivery:

I’ve been working this way for a long time on many systems and I’ll never go back. However, some may disagree and I got a response from one of them.

That’s fair. Continuous delivery is an edge case. Let’s discuss the cases at the edge.

First, we need to make sure we level set on our definition of “CD”. Continuous delivery is a workflow where small changes are made very frequently and integrated into the trunk of version control. From there, an artifact is either certified by the pipeline as meeting our definition of “releasable” or the artifact is rejected and we immediately fix the reason it was rejected. We are always in a state where we can release the latest changes to production. The more frequently we do that, the smaller the changes are, the less risk we will create major defects, and the faster we can get feedback on the value of the change. Why would we want to do this? This is fine for a simple website, but why do it for “real” applications?

Compliance

Another edge case is heavily regulated environments. We need to ensure that we are adhering to all of the standards that the Auditors will be checking. We need to do that on every code change and we need to block non-compliant changes. One common requirement is that there are two sets of eyes on every change to prevent bad actors. We should have compliance gates built into our pipelines to enforce this rather than discovering we have problems during an audit that may have legal consequences.

High Availability

Another rare case is the need for systems to be available 24x7. When there are issues with these systems, we need a standardized approach to repairing them at 3 am while half-awake to reduce the risk of making a bad situation worse. In the rare cases where we are working on systems like this, we need to refine our standard method for delivering hotfixes by using it as the only way to deploy enhancements to the system. In this way, we can use muscle memory and verified quality gates to deliver fixes and reduce impact.

Quality

One other edge case is when we are working on systems where quality is important. It’s surprising, but some software requires a level of quality beyond “hold my beer!” driven development. Quality is a process that requires rapid feedback on quality issues and the ability to address them in a timely manner. Having fully automated and fast quality gates and the ability to deliver small changes to the end-user to get additional quality feedback is very important for systems like these. Only on systems where quality isn’t important should we use artisenal manual testing methods and monthly or quarterly deliveries.

So, how big is the edge case for CD?

If you think it’s pointless, you’ve probably not thought through the problems. It’s fine to disagree but bring real evidence so we can talk through it. I’m happy to learn something new.

If you want help starting the journey, we are trying to simplify it at MinimumCD.org