Recently I tweeted that “Interesting things happen as deployment costs approach zero”. From that I got a few questions about what I meant and why that may be.
Firstly a distinction, I said deployment and not release. They are different things. A release requires a deployment in order to deliver a feature or bundle of features that are needed in a particular environment. But a deployment may infact be the existing artifacts or a set of previous artifacts (for example a roll-back).
What do I mean by the cost of a deployment? I am not talking so much in monetary terms, but more in the energy expended by the members of your team. How mentally challenging is a deployment, does it:
- envoke a sense of fear?
- require a lot of box ticking?
- result in a scramble to get signatures and approvals?
- need hours of planning and scheduling?
- require a lot of typing?
A deployment should not result in any of those things. Deployments often do however and it typically boils down to fear. Fear of making mistakes because it is hard.
The problem with fear of deployment is that it becomes self reinforcing, because we are afraid, because it is hard, we make mistakes which in turn makes us more afraid, which makes us hesitant to do it again and makes it likely for us to add even more sign-offs to make it more difficult to make mistakes next time.
Who has worked anywhere where a release has gone wrong and all of a sudden all releases need to be approved by the CTO/VP/Director or even CEO? Most of us I am betting. Now what happens when that doesn’t actually happen, but rather the process of deployments is made, simple, safe and transparent? This is what I mean by cost approaching zero.
We have observed the following:
- More deployments happen, as there is little penalty incurred.
- The difference between active developer code base and the code base actually running in production drops.
- Time is saved as engineers spend less time considering and debating if a deployment is worth doing. (Or complaining about the deployment process).
- The decision point as to whether as a deployment can be done or not moves from Senior Management down to the group, then down to the team lead and ultimately down to the engineers working on the changes themselves. (This does enormous things for team morale and feelings of empowerment).
You find that as the confidence increases that all of a sudden a deployment for a one line change (and a proper one, not a hack) becomes possible and actually begins to happen. This opens the door for faster iterations, it enables more experiments and for the developers themselves to begin driving incremental improvements such as taking on refactorings that otherwise might not happen.
All of these things add up to a better product, a less fragile product and happier teams.