The goal of every software team is to get the finished product to the end customer. Yet doing this is surprisingly hard for many teams.
In a perfect world, the act of deploying software to production is painless and trustworthy. To know whether you do in fact live in such a world, try answering the following question: can anyone on the team execute a single command and deploy the entire application to production?
If you can honestly say “yes” to all the bolded words, congratulations and thanks for coming. For the rest of us, let’s consider how one goes about making their production deployment painless and trustworthy.
Deploy, Rinse, Repeat
As with many things in life, the more you do something, the easier it gets. Not only that, but you also trust the results more.
If you want painless and trustworthy production deployments, you need to deploy your application to production as frequently as possible. Actually, Continuous Delivery fans advocate deploying every single change you make to your application immediately to the end customer. While this may be a bit much for some (most?) organizations, the ability to do it is pretty appealing.
Frequent practice is important, but it’s not enough. At the risk of stating the obvious, the steps you take to deploy shouldn’t change based on what environment you’re deploying to. In other words, deployment to your CI, test, staging, regression, and most importantly production should be the same. The same scripts should run, the same steps should be taken, etc. Agile practitioners call this a repeatable deployment path.
“Well, of course I should do the same thing in production as everywhere else“, you may be thinking. “Why wouldn’t I?“. Well, the thing is, production is unique. Unlike all other environments, you probably want to minimize or eliminate downtime. This means that you can’t just tear it all down and rebuild from scratch. Not unless you want angry customers.
Hit Me Baby One More Time
One way of dealing with this problem is deploying to an existing server. In other words, you can just take your automated deployment script, point it at an existing production server (preferably one that’s been removed from the web farm), and fire away. The script would presumably go through and update, remove, or add all the necessary components required for your app.
This strategy may work, but only if you do the exact same thing in non-production environments. If, on the other hand, you’re deploying from scratch everywhere else, this strategy is not great because you’re doing things differently in different environments.
The Old Switcharoo
Another way of deploying to production is through A-B deployments (Jez Humble and Dave Farley call this blue-green deployments). The idea is that you stand up an environment identical to production and just cut over to it. This approach is appealing because you don’t have to worry about bringing servers down.
This approach gets you much closer to the goal of having a repeatable deployment path because you can literally do the same thing in all environments.
Painless production deployments are possible. Not only that, they’re well worth the investment. The recipe is simple and requires just two ingredients: automation and consistency. Good luck.
You may also like:
Did you love / hate / were unmoved by this post?
Then show your support / disgust / indifference by following me on Twitter!