Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Standardizing Deployments? Start with Production and Work Backwards

DZone's Guide to

Standardizing Deployments? Start with Production and Work Backwards

· DevOps Zone
Free Resource

Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.

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.

Download the ‘Practical Blueprint to Continuous Delivery’ to learn how Automic Release Automation can help you begin or continue your company’s digital transformation.

Topics:

Published at DZone with permission of Eric Minick, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}