Over a million developers have joined DZone.

Do You Suffer From Deployment Anxiety?

Whether you suffer from a diagnosed anxiety disorder or not, many of us who are responsible for deployments become uneasy when deploying code to production.

· DevOps Zone

The DevOps zone is brought to you in partnership with Sonatype Nexus. The Nexus suite helps scale your DevOps delivery with continuous component intelligence integrated into development tools, including Eclipse, IntelliJ, Jenkins, Bamboo, SonarQube and more. Schedule a demo today

Whether you suffer from a diagnosed anxiety disorder or not, many of us who are responsible for deployments become uneasy when deploying code to production.


Did my tests catch everything? What if something happens during a migration and I can’t rollback? Will that small code change create an unstoppable reaction destroying everything in my database? Okay, maybe that’s a little aggressive, but you get my point. Deploying to production creates anxiety among developers all over the world.

So, how do we combat this anxiety without a prescription for Xanax? We’ve gathered a couple tricks to help ease your anxiety and optimize your release pipeline all at the same time.

Automate Configuration and Deployment

By automating a process, you are turning it into a constant. This is the best way to make sure your deployments behave the same every time you deploy an application. Like we learned during our 4th grade science fair, the control variable is unchanging and will give you confidence to learn from future breaks and failures (dependent variables).

Create a Testing Environment

QA testing should have its own environment and it should be production-like. This is the first major step towards Continuous Delivery and an overall healthier state of mind when deploying to production. Hopefully, you can automate your code’s transition from a dev environment to a QA environment where it can run suites of functional and performance tests. Each QA environment should be complete with the right configurations for each new code release.

Work With Your Support Team

It’s all too easy to get involved with your next project and forget to check in on the apps you already have running. DevOps principles often talk about breaking down the walls between departments and, in this case, that means working with your support team to ensure the health of your existing apps. If you can automate the way existing apps are tested and monitored by your dev and support teams, you will begin deploying to production with a lot more confidence.

Use Canary Releases

Danilo Sato’s definition of a Canary Release on MartinFowler.com is the best I’ve found:

Canary release is a technique to reduce the risk of introducing a new software version in production by slowly rolling out the change to a small subset of users before rolling it out to the entire infrastructure and making it available to everybody.”

By releasing to a small portion of users, you can build confidence in your deployment before pushing it into production completely.

Run Fire Drills

Crashes, outages, breaks, and failures are all terrifying what-ifs. One way to become slightly more comfortable with these uncertainties is to run controlled fire drills with your teams. Come up with some creative, albeit terrifying, ideas like database crashes or datacenter outages, and run through those scenarios and your related response plan with your team.

Incremental Deployments

You can read a full blog on Incremental vs. Full Deployments here, but the basics of it are, by running incremental deployments you are updating only the assets on the site that are being changed, instead of re-creating the configuration of the site as a whole. They are faster deploys and they don’t touch the systems that are already OK.

Dependable Fast Rollbacks

Nothing is more comforting than knowing you can roll back your release. Rollbacks are another process that can be automated so that if/when your deployments break, you’ll notice serious errors quickly. It should be noted that you’ll want to make sure your old code still works on the new database layout, if you were to rollback. Don’t be afraid to re-test your old code before rolling back.

Deploy Often

The most comfortable developers I’ve met deploy to production a dozen or more times a day. This is the result of a Continuous Delivery pipeline. By automating the right processes and deploying often, you will be able to tweak and refine your pipeline to run smoothly. Am I saying you should start pushing out 30 deploys a day? No. But increasing your deployment rates over time will help create a release process that flows with far fewer bottlenecks and failures.

One of the best ways to keep anxiety at bay is by learning from others mistakes. Check out our on-demand webinar: Lessons Learned: Scaling DevOps and Continuous Delivery for the Enterprise.

The DevOps zone is brought to you in partnership with Sonatype Nexus. Use the Nexus Suite to automate your software supply chain and ensure you're using the highest quality open source components at every step of the development lifecycle. Get Nexus today

continuous delivery,qa,pipeline,environment,deployment,canary release,rollback

Published at DZone with permission of Necco Ceresani, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

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

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

{{ parent.tldr }}

{{ parent.urlSource.name }}