Myth 1: Every deployment is unique
In the last post we talked about some of the myths about release and deployment. Perhaps the most telling comment there was the belief that “Every deployment is unique.”
Let’s break that apart and see what it really means and why it just doesn’t hold up in reality.
Deploying an application comprises of a number of parts:
- The “payload” – what is actually being deployed and that will be code, scripts, configuration items, SQL, data and so on
- The “set up” – what you have to do before you can deploy the “payload” like stopping servers, data migration and reformatting and backing up the environment
- The “verify” – the what you have to do to be sure you deployed correctly
- The “startup” – what you have to do to bring things back on the air after you have verified that there has been a successful deployment including restarting servers, re-opening telecommunications, resetting log files
- The “what if” – the steps you need to take if any part of the “set up”, the “verify” or “startup” doesn’t go as predicted
Deployment to multiple targets
Constant inconsistency is consistently predictable
Your application may be simple and confined to a few identical target platforms or it may be n-tiered and deployed to a chaotic topology completely out of your control. Irrespective your deployment will have these 5 elements.
All of these steps are predictable and any variation in the how the steps are executed is determinable. For example if there are no SQL DDL changes in the payload then there’s no need to stop the database. If the web server won’t stop abort the deployment and notify the release engineer.
It might take a release engineer the best part of a day to re-craft a deployment script for each “unique” deployment and even the very best engineers will only have a 99% success rate. If the script executes for an hour every day there will be at least three outages a year and more time spent fixing scripts that actually deploying.
With Serena’s Deployment Automation solution you spend less time developing scripts because the whole process is entirely graphical. You get to reuse elements for deploying to standard environments like Oracle database and the Amazon cloud. You get to spend more time thinking about what to do if the deployment fails and you get to build in all the logic you need so that even the most diverse and complex deployments become commonplace and predictable. Your release engineers spend their time improving and automating and Serena Deployment Automation takes care of everything else.
You can learn more about deployment automation at serena.com.
