Ok, so AnthillPro is all about automating the build lifecycle: building, testing, deploying and all that good stuff. Go to the front page of AnthillPro.com and you'll see "Build. Deploy. Test. Release" displayed prominently - as it has been for years. That's the heart and soul of AnthillPro. But what happens when you strip all that away?

Well, you end up with a distributed, schedulable workflow engine with access to a well categorized grid of agents. While not nearly as entertaining as automating the build lifecycle, this can be a pretty handy tool as well. Want to restart the application servers on all the machines in QA? Or retrieve logs from production, scrub them, and deliver them to development? Or kick off the weekly backup? A number of teams use AnthillPro to do this sort of work, but most don't think to consider it (hence the blog post).

In fact, there are features built into AnthillPro specifically to support using it for these more generic operational activities. When you create a new project in AnthillPro, you see a dialog asking if you want a "Lifecycle Based" or "Non-Lifecycle Based" project. Most Anthill users always pick Lifecycle based because that's what makes sense for a software project that's built and promoted. Unlifecycled projects are there to strip away all the statuses, stamps, build lives, and source control magic that provides context to the build lifecycle and leave a more pure distributed workflow system, that's full of integrations, and built in steps.

I'd challenge teams that have rolled out AnthillPro to look around for those annoying, repetitive system administration tasks. Once you've found them, look to see if AnthillPro can be used to automate them, and take advantage of those non-lifecycled projects.

Lean teams will defer commitment on high risk decisions. Generally this means that instead of putting a lot of time and effort into making sure they make early, risky decisions correctly, they avoid the high cost of incorrect decisions by finding ways to defer making the commitment.

In this entry we look at how build and release teams can defer some of their high risk decisions saving their organizations money and the team a lot of stress.

Read more...