Anti-patterns in Deploying Software

a couple of years ago

The biggest challenge in software development industry is how to turn somebody’s good idea into application as soon as possible. To do this there are techniques and good practices we have to do. We must always follow deployment pipelines.

deployment pipeline

deployment pipeline

Taken from book Continuous Delivery – Reliable Software Releases Through Build, Test And Deployment Automation

But first to know how to do this good practices we must know what ant-patterns we are doing continuously in our software deployment.

First anti-pattern is deploying code manually.

People are generally stupid, in a way that we are not programmed to do repetitive assignments very good. Computers are. So why not automatize the whole process. The manual work should only contain two actions. Selection of the version that will go to production and pushing deploy button.

Signs of this anti-pattern are:

  • Detailed documentation that describes how to push code and a lot of dos and don’ts that must be followed blindly.
  • Reliance only on manual testing to confirm that application is running correctly
  • Frequent calls directly to development team to explain why deployment is going wrong on a release day.
  • Frequent corrections to the release process during the course of a release
  • Releases that take more than a few minutes to perform
  • Releases that are unpredictable in their outcome, that often have to be rolled back

Second anti-pattern is Deploying to a production-like environment only after development is “done”

This anti-pattern looks like this:

  • Testers tested the code only in dev environment
  • Releasing into staging is the fist time that operations interact with new release. In some organizations separate operations teams are used to deploy software into staging and production. In this case the first time operations person sees the software is the day it is released into production.
  • Production-like environment is expensive to create, or accessing is strictly controlled, or it is not in place on time, or nobody bothered to create one.
  • Dev team assembles all the scripts and tools to operations to perform the actual deployment and all of it is untested in an environment that looks like production or staging.
  • Communication is broken and there are no collaboration between development teams and operations.

When Working on a new application the first deployment to staging is going to bring problems. Chances for this are doubled when development is being done on a Linux machine and that is being deployed to server running Windows. If application is installed by users you may not have much controller over their environments so this could be a big issue.

Third anti-pattern is Manual configuration management of production environments

Signs of thid anti-pattern are:

  • Deployment to production fails, even if there are many successful deployment to staging
  • The operations team take a long time to prepare an environment for a release
  • There are no roll-backs to earlier configuration of your system (OS, RDBMS, web server, etc…)
  • Configuration of the system is carried out by modifying the configuration directly on production server

Can we do better? Of course we can. In the next article I will describe solutions to all of this problems listed here.

This article is inspired by this book: Continuous Delivery – Reliable Software Releases Through Build, Test And Deployment Automation

 

Anel Bejtović

About the Author

Anel Bejtović

29 year old software developer and beer brewer from Mostar, Bosnia and Herzegovina, currently living and working in Frankfurt am Main, Germany.

Follow Anel Bejtović: