AnthillPro dependency reports

Earlier in the week, I presented a webinar on managing build time dependencies which is now available as a recording. In it, I showed a fancy dependency diagram and suggested that any of my AnthillPro customers could generate that by loading in a custom report.

Naturally, you all emailed me. Our wiki has it. There are two reports to be found here: http://wiki.urbancode.com/AnthillPro/AnthillPro_Velocity_Reports both starting with “Interactive Dependency Report” in the name. The VML one is Internet explorer specific. The SVG one works for everyone else.

To apply the report, go to System > Reports and create a new velocity report. Be sure to check the build life integration box, and paste the code into the main report area.

Integration Update

A number of new and updated integrations have rolled out recently, here’s the run-down.

AnthillPro – Jira 4.x

The folks at Atlassian changed up their web services schema. The latest plugin for Jira supports the new Jira web services. You can get it here. If you’re still using the legacy integration rather than the plugin, migrating to Jira 4 is a good time to switch over.

TFS 2012

We’re starting to see some adoption of Microsoft Team Foundation Server 2012. Updated integrations for it are now available. They’ll be shipping in uDeploy 4.8. AnthillPro and uBuild integrations are around the corner as well. If you need this integration before the next release, contact support for a patch.

Tomcat

The uDeploy integration for Apache Tomcat has been updated with support for moving over a specialized context.xml with a war file deployment.

uDeploy – Jenkins

This has been available for a little while now, but we should mention that the Jenkins plugin for uDeploy has a couple of enhancements. First, it now supports Jenkins slave builds better. Second, it can be configured to automatically trigger a deployment of the new version in uDeploy.

uDeploy / ServiceNow

This integration was expanded to cover ServiceNow’s CMDB offering.

What’s Next?

Tell us. When it comes to integrations, we’re all ears. Ok, ears and nimble coding fingers.

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";

 

AnthillPro tip: optional paths

A number of AnthillPro integrations point at command line tools that may or may not be on the path. Source control integrations are typical example where the CLI interface for the SCM tool is generally on the path but sometimes is not.

To compensate, the integrations offer users the ability to specify a command path. If the tool is installed in different locations on different machines an agent property is usually referenced: ${a:path_to_tool}

This approach works, but requires configuring the parameter for every agent – even those who do have the tool on the path. When many agents already have the tool on the path, we can refine a little further. Turn the property into an optional property (that resolves to empty if there’s no value) like this: ${a?:path_to_tool}.

With the question mark included, the command path can be set on an agent by agent basis if required. For agents that already have the tool on the path, you can safely skip the configuration.

AnthillPro Jobs Round-up

My inbox has been littered with AnthillPro job opportunities over the last few days. Here’s a sampling.

Blackhawk Networks (Pleasanton, CA): Senior Build and Release Engineer

Comcast (Philadelphia): Build Engineer

Disney: (W. Disney World) Application Developer – Build & Environment Management

Macys (Greater Atlanta area): Sr. Analyst Infrastructure Architecture

Macys.com (Bay Area): Release Engineer and Tech Lead, CI

Mathworks (Boston): Web Applications Release Engineer

Media / Publishing (London): Enterprise Release Manager

Urbancode (Cleveland): Product Specialists & Pre-sales Engineers

Visa (Bay Area): Release Engineer 

 

Did you catch how I snuck us into the list? If you love helping people from great companies around the world, and know some AnthillPro (or even a lot about build and deployment in general) we want you on our team.

AnthillPro 3.8.3 Released

The March 2012 release of AnthillPro was focused on bug fixes, but a handful of nice little features were added as well to deal with common headaches:

  • Read only views of configuration: Editors used to be the only ones who could view the configuration of projects, workflows and jobs. Now, those with “read” only permissions can review the configuration if granted rights to the Admin tab.
  • Visibility into inherited properties: The project-environment property screen also shows inherited properties from the system, environment or project along with where the value was set.
  • BuildLife Deleted Event: An internal event fires when a build life is deleted. If you want to send emails or launch processes when BuildLives die, the hook is available.
  • Tweaks to “keep at least X days” cleanup rules: The calculation can now be based either on the time since the BuildLife was created, or since the status was applied.
AnthillPro users can find out more about 3.8.3.