In managing today’s IT operations, there is growing interest and enthusiasm for release automation software. These solutions promise to dramatically improve the quality, speed and reliability of application releases. Vendors push capabilities like faster, error-free releases for improving business responsiveness.

Yet, despite the high expectations set by deployment automation, release validation actually plays a vital role in this process, maintaining optimum performance and preventing harmful downtime.

So the question is then, why spend the extra time and trouble to validate releases, after all deployments can now be automated, and everything is supposed to run as planned – no surprises, right? There are a number of strategic areas to look into where deployment automation by itself still falls short, and the release process is complemented by release validation.

Area #1 – The Environment Model Only Maps What is Already Known 

Automation tools create models of an environment’s configuration. They establish these models in different ways, but the goal is the same – to model the environment that is going to be created. The configuration data model captures a snapshot of an application environment’s configuration, including configuration item details and interdependencies.

The problem with these models is that you are only modeling what is known, not the unknown aspects.

This can been seen in an example where you are deploying to Microsoft IIS, and you want to change the connection timeout parameter. So, you set the parameters that you will be changing. But there are hundreds of parameters that can be changed in IIS. Do you know what parameters there are, and what they are supposed to be?

The way that you deploy in one environment may not be the same as another environment. There are aspects of the Microsoft IIS configuration that are impacted by its native deployment. This environment model is not comprehensive and does not include everything.

This model produces something that you don’t have 100% control over, rather only those parameters that were actually defined, leaving the deployment exposed to failure as it advances through environments.

Area #2 – Automated Deployment Tools Are Not Fully Automatic and Complex 

Despite being defined as automated tools designed to streamline the release effort, these automated deployment tools are really not fully automatic. These tools need an operator to configure them and the operator needs to ensure that the results will be error-free.

This is similar to what happens in software development, where bugs can come up during the coding process. In the same way, the deployment automation system contains bugs, even after you used it to deploy your release.

The fact that you first released to a test environment, then released to production, won’t ensure that the releases are consistent. There are many different kinds of configurations and dependencies specific to each of these environments.

Since these tools can contain such errors, validation of releases is vital for ensuring stability.

Area #3 – Don’t Think You Achieved 100% Automation

Besides all of the automated changes that these tools implement, there are many manual actions that often take place. Very rarely do automated deployment tools comprise 100% of the deployment and maintenance activities.

The reality is not that the deployment has been fully automated and the system doesn’t need to be touched. Sometimes, after deployments, configurations need to be changed. Individually changing configurations creates discrepancies.

That is to say, the environment will include both automated and manual changes. That means changes are defined outside the automated tools, and can fall through the cracks in the deployment process.

The impact can be powerful. For example, in a production environment, the operator changes an image or a configuration parameter and then forgets about the changes. The result is that the automated deployment tool wipes out all these manual changes, making the situation even worse!

In Summary: Why Release Validation is Critical for Application Releases 

  • Automated Deployment tools only define part of the environment, leaving you without full authority that the environment that you launched is functioning the way you planned it to
  • Automated Deployment tools are manually configured and can contain bugs, so you need to verify that mistakes and errors don’t impact deployments
  • There is no automation for everything, since in many cases a percentage of manual changes take place either before or after deployment that can contribute to discrepancies, destabilizing the environment

While automated deployments can run perfectly, they do not verify for all configuration settings. Automation actually complicates the process. When a problem occurs, looking for the root cause can be a huge effort.

Release validation complements deployment automation by comparing and verifying what you had already checked and changed, identifying any changes that were not implemented by the automated deployment tool.