I was recently invited to be a guest on a podcast in which I talked about my approach to Continuous Deployment without automated tests. The host asked for an example of this having worked for me in the past, so I shared my experience helping Lana.

When I joined in January of 2020, only the CTO had the knowledge and ability to deploy software to either the staging or production environment. This meant that, in a best-case scenario, a developer had to contact the CTO via Slack or by walking across the office, and ask him to deploy the latest version of his service. If the CTO had nothing else to do, the deployment could be live within a few minutes.

The more common scenario, of course, was the CTO responding with something like “Actually, before I update that service, I need to update another service it depends on, and tweak some config. I should have time on Tuesday.”

The net effect was that deployments happend probably once per month on average, and often involved many microservices simultaneously. This frequently meant rolling back a specific service (or more than one), and mentally blocking that service for upgrade until any bugs could be isolated and resolved.

My first week with Lana, I met with the CTO and CEO, and discussed my plans for Lean CD, or Continuous Deployment without automated testing first. The CTO was enthusiastic to no longer be bothered with manual deployments, but they were both naturally concerned about the implications this might have for quality.

As usual, the biggest obstacle to Continuous Deployment was the fear of losing control over quality. I explained that all of the existing checks would remain in place, they would simply happen before the “merge” button is pressed. They tentatively agreed, and let me get to work.

Jump ahead 9 months, and we had every one their (10 or so) microservices running with continuous deployment, and we were regularly doing 160 or more deployments per week.

There were times when defects made it through into production, but this was the case before Continuous Deployment too. And in the new world, neither the CTO, nor any other human, ever got involved in deployments (or rollbacks), because the automation took care of all that, giving control to the developers doing the work.