Eric Reis has a great post of what it takes to employ continuous deployment on serious applications.

Things Eric says CD provides to / demands from the QA guys:

• Faster (and better) feedback.
• More automation
• Monitoring of real-world metrics
• Better handling of intermittent bugs
• Smaller batches

I'm not sure that fully automated deployments to production can work in a heavily regulated environment, but using the same principals to deploy new functionality out to various test environments automatically is something we've seen be extremely effective.

We're pleased to release a new plugin for running Ruby scripts. Teams have been running Ruby scripts through the shell builder for quite a while and now have the option to use a full integration within AnthillPro.

We allow you to track specific versions of Ruby or use a whichever happens to be installed on a machine and  offer the standard Builder features: dealing with parameters, switches, and working directory offsets.

View a 4-minute demo of the integration.

Then Download the plugin.

AnthillPro notification schemes are made up of three pieces. A template for the email (or IM) to go out, an event selector to determine when to notify, and a recipient generator that chooses who to mail to. The simplest form of recipient generator is the "Fixed" kind that just notifies some list of fixed addresses.

In 3.7, we loosened the definition of "Fixed" by allowing the values in the selector to reference properties. This has some interesting effects. For instance, we can create a selector that mails existing team mailing lists that adapts itself to each project. The selector might be configured to mail ${property:mailing-list}@mycompany.com. If my project has a "mailing-list" property set to myProjectTeam the notification will go to myProjectTeam@mycompany.com. Likewise, we could create a "team lead" property on each project for a scheme that emails the team lead on every failure.