An interesting question came across the AnthillPro mailing list a few days ago: How do you put in place a quote that limits how many builds and tests a single developer can currently run in our build farm? When builds/tests are somewhat costly, it’s reasonable to want to keep individuals from monopolizing a shared pool of machines.
In AnthillPro, the ideal way of restricting access to some resource is with a lock. Usually, a lock represents a shared resource like a database, or network deployer that can only be used by one (or a handful) of processes at a time. In this case, what was needed was a restriction to “my current processes”.
What ended up working was creating an AnthillPro “Lockable Resource” per user. Each user could then be assigned an individual maximum number of current workflows to execute. The build and test workflows are then assigned a scripted resource lookup:
The script would be something like:
return BuildRequestLookup.getCurrent().getRequesterName() + "-quota";
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.