Build Farm throttling by user

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: reduce outage windows by 90%

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.

Customer Success Story: A DevOps Team by Any Other Name

Provides Just as Much Value

I recently visited a customer and was surprised to learn just how sophisticated their IT operation is. They have a private cloud for Dev and Test and automated deployments (courtesy of AnthillPro) across all environments. The development and QA teams may request an environment for a specified period of time and then deploy their build to this environment for testing. This entire system, the environment provisioning and the application deployment is fully automated and turns what used to be a multi-week process into a one that literally takes minutes. BTW, these environments are non trivial as they are made up of multiple virtual machines along with network configuration, firewall rules, load balancing, edge caching, and more. Continue reading