I've had the privilege of working closely with a number of customers to help them get up and started quickly. I also keep an eye on our support traffic. In both cases, I see new Anthill users who are impressed with the tool, but a little unsure about where to start.

Start Fast, Be Happy

I believe in immediate gratification, so the first place to start is to get your project building. The Simple Project Configuration tutorial is a great place to start. By following the example there, you should have your project up and building pretty quickly.

Understand Your Project

That feels good, but AnthillPro is all about automating the lifecycle of your project, not just the builds. So you need to figure out what your project’s lifecycle is. What happens to the products of my build before they reach production or release? Where are they deployed? Who tests them? How do the testers get a copy to test? Are there special release processing or packaging steps that happen after the build and prior to the actual release? You also need to understand the relationships between your projects. This is worth thinking about away from Anthill.

Once that is understood well enough, we can return to Anthill. Anything we don’t understand well enough now, we can always come back and change. Start by creating a status group that specifies the names of the stages of the lifecycle your project(s) move through.

By this time, you should also understand what environments the project will be deployed to for testing, so you can create those environments even if at first they all point to a single test machine.

Then create an artifact set group that describes the kinds of build products (artifacts) you will manipulate separately. For a server-client application you probably have ‘server’ and ‘client’ artifact sets. For an n-tiered web application, you probably have ‘static content’, ‘web-app’ and ‘database’ artifact sets. Anything that might be deployed, tested or manipulated separately gets its own artifact set.

At this point, we have a project that builds, and the names of its lifecycle phases and a description of the kinds of artifacts it produces.

Build Out the Configuration

Now, we want to capture those artifacts. Check the dependency tutorial or the upcoming deployment tutorial for a good description of capturing artifacts.

Once this is working, the artifacts will show up on their tab when looking at a living build. That is wonderful and all, but we still want to do something with them. To do that configure a new generic job that resolves the artifacts to the target machine, and runs any deployment or testing commands against those while marking the build as having advanced to the first non-build phase in its lifecycle.

From here, it’s a matter of making the process generic so that deployment can happen on any environment. Pull those passwords and other environment specific properties out of the commands you ran and into environment specific properties configured at the project level. Script promotions to stages based on where you are deploying if need be.

At this point, you have Anthill doing some pretty sophisticated things. You can work on dependency relationships between projects, notification rules, etc.

Start simple. Understand your process. Build up piece by piece.