- Continuous Integration - Builds triggered by repository commits; adjustable quiet period; configurable feedback for the development team.
- Distributed Build Farm - Distribute build load across your build farm; split builds to run on several agents for speed.
- Living Builds - Manage builds through the entire application lifecycle from development to release and production.
- Dependency Management - Traceable provision of artifacts from one project to another; support for dependencies on third-party artifacts.
- Configurable Workflows - Embedded workflow engine enables definition of custom processes such as automated tests, promotion, deployment, etc.
- Distributed Role-Aware Deployments - Deploy a multi-tiered application to the database server, application server, and web server simultaneously.
- Compliance out of the box - Role-based security, LDAP integration, traceability, auditability, separation of responsibility, and reports.
- Versatility - Runs any build tool. Integrations with Ant, Nant, Maven, Make, and Groovy. Can run any command line.
- SCM Support - CVS, ClearCase, Harvest, Perforce, PVCS, Starteam, Subversion and VSS are supported. Accurev, Dimemensions, Synergy, and BitKeeper Integrations are in progress.
- Robust Notifications - Configurable notification schemes send the right information to the right users on the right medium at the right time.
- Scheduled Builds - Builds and workflows can be scheduled using recurring schedules or delayed using one-time schedules.
- Dependency Aware Triggers - Kick off builds based on events in the dependency graph.
- Codestation - Track dependencies on other Projects and third-party artifacts.
- IDE Plugins - Developers can interact with AnthillPro and pulldependency artifacts from codestation using Eclipse and Visual Studio plugins.
- Integration Friendly - SOAP interface, remote scripting, RSS feeds and custom XML report generation.
Urbancode is pleased to announce the release of AnthillPro3, our third generation Build Management Server. AnthillPro3 is built around an embedded workflow engine and a grid computing engine, making possible definition and automation of processes such as distributed builds, automated tests, promotions, deployments, and more. These capabilities go beyond a build management server and make AnthillPro3 a lifecycle automation server. AnthillPro3 introduces the concept of a Living Build, a model of what actually happens as a build moves from development to release. Living Builds allow secondary processes, such as automated tests, promotions,and deployments to be performed on the build artifacts. The results are then associated with the original build regardless of when the secondary processes are run. In this way, AnthillPro3 produces a comprehensive view of the history of a build as it travels through the application lifecycle. Usage scenarios detailing how to employ AnthillPro3 for various tasks including Continuous Integration, Deployments, and Performance Testing are available on the product website. Key Features:
- Posted by: Eric Minick
- Posted on: October 26 2006 13:27 EDT
- How is this different from CruiseControl? by Joseph Ottinger on October 26 2006 14:12 EDT
- Re: Urbancode announces AnthillPro 3.0, lifecycle automation ser by alex girchenko on October 27 2006 04:56 EDT
- Re: Urbancode announces AnthillPro 3.0, lifecycle automation server by Erik Gollot on October 27 2006 05:50 EDT
- Re: Urbancode announces AnthillPro 3.0, lifecycle automation ser by Par Eklund on October 27 2006 06:57 EDT
- Re: Urbancode announces AnthillPro 3.0, lifecycle automation ser by Eric Minick on October 27 2006 11:04 EDT
- CruiseControl Doesn't Always Cut It by Tim McNerney on October 27 2006 13:07 EDT
So... how is this different than CruiseControl?
That's a fair question Joe, and one that comes up every time a commercial build tool is presented on TSS. Cruise works for people, and it's free. A commercial tool better have something more to offer. First, let me say that CruiseControl is a good tool for implementing Continuous Integration. It's also probably the industry leader in turning on lava lamps. That's half a joke, and half not a joke. Where Cruise excels is in checking out your project regularly, building it, running your tests and and giving you lots and lots of feedback about that state of your one project, right now. Lava lamps are an interesting way to provide that feedback. However, on a daily basis, my software development experience involves working with projects that depend on each other. I also hear from testers about problems in last week's builds and from users of my software who are having a problem with a version that is two years old. I need more than feedback about the current state of a handful of projects. That's where build management servers start to shine. A continuous integration tool, like CruiseControl, gives you feedback on the state of your project right now. The Build Management Server edition of AnthillPro3, supports CI (with commit triggers, quiet period, and intregrated Junit test results), while tracking my historic builds and providing rich support for dependencies. It also will manage a build farm. AnthillPro is also a Lifecycle Automation Server. At this level of functionality, it deploys the build QA just approved, has custom promotion workflows and does the things that make auditors happy. There's a feature list up the page, so I won't go into more depth here. It becomes very apparent that we are not talking about tools that have similar goals and ambitions. CruiseControl is a very good CI server. But it really isn't a build management server and it definately is not a lifecycle automation server. So why should you consider a product like AnthillPro when CruiseControl works and is free? Because you want more than a single-server CI application.
Pricing starts at $999 USD for small teamsSmall teams would likely prefer Hudson (https://hudson.dev.java.net).
Not sure it's necessary to pay for such kind of tools (AntHill, Build forge,...). Continuum + Maven or Ant + CruiseControl can really be enough. The deployement features of such kind of tools are usually not compliant with the internal procedures and using a workflow for the different deployment phases is not really flexible.
It's funny how every time a commercial tool makes an announcement on theserverside, people immediately go to great lengths to find reasons not to use it and suggest a combination of OS/"free" tools that could do the job just as well. Why it that, one could ask. Let me make a few educated guesses: * OS/free tools, in general, are often quite powerful, but they almost always require enough competence (to use and or integrate with other OS tools) in order for the particular developer/OS advocate to be indispensable in his current line of work. Go figure... * There is no vendor-management connection that keeps the developer out of the decision loop. I guess this is a mixed bag of curses and blessings... * Developers tend to instinctively see that if A is good then B must be bad (especially if B is non-OS). One could argue that A + B actually is better than A or even better than A and B used independently. So, what I'm saying (as a long-time OS user and developer) is that it would be nice to see a little more openness towards commercial tools as well. They are not there to take your toys away from you. It is a potential (not all commercial products are good of course) for improvement in terms of software longevity, support, documentation and overall maintainability (since a guy whose salary depends on it is maintaining it, not you or some enthusiast in his spare time). And as such, it could save _you_ time and possibly even your butt, used standalone or in conjunction with your favorite OS tools. And why not evaluate a product based on its own merits and not its purchase cost or whether its source is open for you to see? In the long run, the license cost is a small part of the TCO. And also, is there really a clear distinction between OS and "commercial software"? Isn't OS just another business model, a natural evolution of "first fix is free", which just happens to attract such a huge crowd of outspoken followers...? Now, on to evaluate AnthillPro 3.0. :) Have a nice weekend /Par
Not sure it's necessary to pay for such kind of tools (AntHill, Build forge,...).Thanks Erik. I agree that for just continuous integration you can get away with Cruise or Continuum. It's a matter of what you need from the tools. That's the gist of my response to Joe. I'm curious as to why you would think the deployment processes wouldn't comply with internal procedures. Typically, what we see is that development does some builds until they think they have one that's 'pretty good' and they hand that off to QA. Ideally this is done by giving the artifacts to QA and having QA deploy them, but lots of the time QA doesn't know how and the dev team sneaks in the deployments. How this changes with the tool in place is that development writes deployment scripts. Then they run an action on the tool to hand the build to QA. That prompts the QA leads with a big fat 'Deploy' button that runs those scripts on the appropriate server(s) to deploy to QA. Similar processes would be available to UAT or Production or whatever environments you have. Ideally your deployment to QA is the same as the deployment to Prod but with some (often secure) parameters tweaked - like database passwords. What the processes are and what steps actually make up a deployment are things we have no way of knowing. Everyone does it differently. It's up to you to define your steps. Usually people can define steps and processes that mirror thier existing approaches while addressing the 'only the developer knows how to deploy' problem.
Continuum + Maven or Ant + CruiseControl can really be enough.
The deployement features of such kind of tools are usually not compliant with the internal procedures and using a workflow for the different deployment phases is not really flexible.
I've worked with CruiseControl for several years now. And it has worked for us, but not without a lot of work on our part. And even with that work, it leaves a lot to be desired. It is generally speaking, a pain to work with, but was far too valuable not to make the effort. We have recently moved to a commercial CI system and it is a blessing. The amount of time I spent tweaking, debugging and threatening CC, along with the amount of time that will be saved with our new systems more advanced features and ease of use make the commercial CI server much cheaper than the Open Source one. Open Source is great when it works and serves your needs. But free isn't always better. --Tim