Over the course of my career, I’ve heard similar refrains regarding the deployment of changes to running systems. In fact, I’m amused to have experienced several different teams independently coin the term “change prevention program.” While we all get a good laugh at the irony of it, I worry that there is some truth in their jest. Building up to a deployment often signifies accomplishment and completion, but for many, that build-up carries with it fear of the unknown and memories of past failure. Furthermore, the risks of software deployment are often misunderstood, and these fears are often used as justification to impede deployments, delivering changes less and less frequently to minimize the possibility of failure. This destruction of the confidence in a team and its tools can have a profound effect on a project and, indeed, the entire organization, but responding in the opposite way can be just as impactful.
Discovering What You Don’t Know
Each deployment of your project should be seen as an opportunity to learn about what you do well and what needs to be improved. Deploying often will help your team differentiate between simple, quick improvements and systemic problems that require more time. Picking some of that low-hanging fruit builds early confidence in more frequent deployments and gives you demonstrable progress to show management when requesting time to work through the tougher problems.
Leveling Up
Easier deployments also free you to consider the bigger gaps in your knowledge. A lot of tooling has cropped up in recent years to enable better control over server and runtime configuration. Docker, Ansible, Puppet, and others exist to make your application environment more predictable. And once you can replicate and modify the entire environment, experimentation and collaboration become easier because you have far more control over the entire list of your project’s dependencies. Now you’ve moved beyond addressing your team’s pain and into expanding their capabilities.
Developer Happiness
We’ve talked about pizza deployments before, and while we all love pizza, eating it at odd hours while at peak project stress isn’t a recipe for happiness. We would all rather be deploying changes on a weekday afternoon during normal working hours. This is incredibly convenient for us, but if our deployment processes aren’t reliable, we can’t have this convenience. I don’t think it’s a stretch, then, to say that frequent, practiced deployments are a direct contributor to developer happiness. This happiness, coupled with increased confidence among those who rely on you, might be the most valuable thing you can add to your project.
