Configuration only deployments were one of the big features added in the 4.7 release of uDeploy. The idea is pretty simple. If your application code didn’t change, but a setting you track in uDeploy (such as a timeout, url to a web service, or thread count) did change, then you should be able to deploy the configuration update without redeploying the application.
I don’t think I fully understood the impact of this capability until I talked with a release engineer last week. On one of his projects, the full automated application deployment takes about 20 minutes. However, if he only deployed the configuration, the process could be reduced to 2 minutes. That’s a factor of ten faster. When a typical release impacts upwards of 50 different applications in this system, the improvements multiplied. This was really exciting, since outages were painful and configuration changes much more often than application code. For this team, only one out of every five deployments modified the application.
Configuration only deployments meant that they could reduce 80% of their outage windows by 90%. That’s just awesome.
There are two good lessons here:
1) When a new version of an application you use comes out, really look for opportunities to exploit new features.
2) If you’re doing automation, regularly look for waste in there and try to eliminate those extra steps. We have a whitepaper on using Lean techniques in build and deployment automation that might point you in the right direction there.


Hi Eric
How is the configuration versioned? At the same pace as the application?
Steve
For uDeploy, and configuration change results in a new version.
In AnthillPro terms, that means that if you changed some project-environment properties there would be a new version of those project-environment properties. Each deployment includes a manifest of the collection of application versions and configuration versions that were used. Snapshots allow you to put all of that into a bundle and approve deployments and config.
Pingback: News, September 25 | The Build Doctor
Pingback: Is the DevOps community setting the bar too low for automation tools? « Newtonian Nuggets