Just don't call it "Continuous delivery"

Hi BigCo. So you do continuous delivery. Congratulations! it's both cool and good business sense to be fast-moving like that. And it's not easy. It requires taking the high road on some tough choices. If it was easy, everyone would do it.

There is some merit to the argument that the number of deployments is a vanity metric - past certain point it is: there is little point in inflating the deployment count by changing 1 line of code, deploying it and then changing another line, deploying that and so on. It's also misleading - I have heard it said that "StartUpCo deployed their whole system 50 times this week" when I knew from inside that there were in fact 50 deployments to components or confiigurations of the system, and the majority of those had no effect on most customers at all, e.g. improved the logging and metrics, addressed a particular error case, or or were work in progress that wasn't handling live traffic yet.

But being able to deploy a single change rapidly is very useful. You can find out the effects quickly, even if it's a tweak to code, to logging and metrics. And we know how bunching changes together increases the risk of each deployment. If you only deployed one code change, then you know where to look if the behaviour changes. It's a powerful way to increase confidence with the code. You get better at working on a codebase by working on that codebase, so best to get stuck in and understand the results in action.

Continuous deployment is a high-trust process. I don't mean that just in the abstract, top-down sense of "the business owners have decided to trust the coding team" platitudes. I mean it in bottom-up, engineering-led sense: you need to have confidence in your code, that the green mark means something, that code that you push to your git server is throughly unit tested, integration tested, deployed to a staging server and tested in situ there. That deployments are one-click or no-click processes that don't vary, that there are smoke tests, stats and metrics and alerts on the live system, and you can roll back easily and fast if these waver. That this all happens every time. This trust can build up organically and flow up the chain of command, not down.

The core of continuous deployment is reducing the cycle time and key techniques are removing manual steps and visibility at all stages.

So, BigCo, you made some choices. It's continuous, you say. And there are few things to learn. I get it, your staging server is a whole fleet of VMs and services in a cloud provider. I know it takes half an hour to spin that all up, and you can't afford to keep a build agent waiting for that to finish every time. so you took the decision to let the build script complete after a few minutes when the clouds provider receives the script. So the tests on that staging environment are run when coder triggers them manually. There are good reasons for it. And anyway, the test coverage isn't actually all that.

And your pull-request based work flow. there are good reasons for it, I know, even though I am less familiar with what they might be. But a side effect is that code can sit waiting for days, increasing the cycle time by orders of magnitude for this low-trust, manual step. Did you spot the three ways this is anti-continuous?

I know, you looked at those choice-points and took the other path for valid reasons.

Thing is, if continuous deployment was easy, everyone would do it. It's hard.

I'm sure that those choices are valid. It doesn't matter. I just ask that you don't call what you do "Continuous delivery" any more. I could base that on the measured cycle time, but actually I base it on the expressed preference of your choices.