DevOps Zone is brought to you in partnership with:

Leaving university, I thought I'd be a developer happily knocking out code but was always drawn to tech support. How do we help people use our tools better? Now, I mostly specialize in consulting and introducing new customers to our tools. I am a Tech Evangelist and Lead Consultant at Urbancode. Eric is a DZone MVB and is not an employee of DZone and has posted 77 posts at DZone. You can read more from them at their website. View Full User Profile

Standardizing Deployments? Start with Production and Work Backwards

  • submit to reddit

We’re often asked where to start when organizations want to standardize their deployment processes across environments. Starting with the deployment to development environments is common. Developers extend their continuous integration platforms towards continuous delivery organically, deploying to dev test environments for simple functional tests. And later to QA environments using similar approaches.

Many of these organic efforts stumble when they get closer to production. The production deployment often differs so much from the development deployments that the automation can’t be tweaked to meet the challenge. Common tripping points include the inclusion of clusters, load balancers, backups and databases (where dropping all the tables isn’t an option in production). This is so common that most continuous delivery efforts stop at a test environment and aren’t used for staging, production or disaster recovery environments.

Having seen teams reach this stumbling block over and over again, I’m increasingly convinced that for a common process to be created, you have to start with the production deployment process and work backwards from there. For databases, that means that development deployments should use incremental updates to databases rather than a drop and recreate approach. Having a load balancer in QA would be nice, but if it isn’t present, the automation should have a switch in it for, “If there’s a load balancer….” otherwise skip this part of the deployment.

Essentially, the goal is to move from a situation where dev and production deployments are “different” to one where the dev deployment is treated as a simpler version (a subset) of the production deployment. Once a common process is agreed upon (even if its just on paper at this point) standardization and automation efforts can begin in earnest with a good chance of success.

Published at DZone with permission of Eric Minick, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Simonluca Landi replied on Sat, 2012/12/15 - 3:56pm

I completely agree with you. In my company we are using the same rules: we (try to..) build every environment using the same recipes, this is why we use virtual machines for all the enviroments, from the dev laptop to production systems. Using virtual machines and "recipes" simplify the setup: you start from the design of the production environment (load balancers, multiple frontends, DB replicas, etc... ) and simply "collapse" the same components in less virtual machines, up to a "all in one" virtual machine that the developers can use their laptop.

Another important lesson we learn is that you should deploy the software in all the enviroment in the same way, using the same tools/scripts/etc.. In this way you build more and more confidence in your deployment procedures.

For the interested ones, I started to share what we are learning in my blog 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.