Why Release Validation is Critical for Effective Deployments and Releases
Agile software development is racing to meet the ongoing and changing demands of today’s business services. This means IT ops needs to manage the complex process and hectic pace of deploying releases and patches – faster than ever. To meet this demand, IT operations professionals have enthusiastically turned to release/deployment automation software.
The enthusiasm comes out of the promise that these solutions can dramatically improve the quality, speed and reliability of application releases under these frantic conditions. Software providers promote such benefits as faster, error-free releases that improve business responsiveness. Yet, despite the hope nurtured around the prospect of deployment automation, the process is not bullet-proof and release validation actually plays a key role for maintaining top performance and to prevent harmful downtime.
So then the issue is, why should IT Ops put in the additional time and trouble to validate their releases? The assumption is that since deployments can now be automated, so everything is supposed to run smooth and as planned – with no surprises, right? Wrong.
In considering this question, there are a number of important areas where deployment automation on its own still does not deliver on their promises, and ultimately the overall release process is only finally completed by validating the release.
#1 Modeling What is Already Known Misses the Potential Problems
Release/deployment Automation tools create models of an environment’s configuration. These models are established in different ways, but the purpose is the same - to model the environment that is going to be created. The configuration data model captures a snapshot of the environment’s configuration, including configuration item details and inter-dependencies.
The problem with these models is that these models are based on what is known, not the unknown aspects. When deploying a complex technology, like Microsoft IIS web server that contains hundreds of parameters, the configuration can be updated and changed over the deployment process. The Release Manager may not be aware of 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.
Continued on the next page
Follow Technorati