In our first post looking at Scrum and the Build Server we focused on the interaction between the Build Server and the individual build team. In this follow up, we take a look at how scaling agile practices like Scrum to a larger organization impacts the relationship with the build sever.

Read more...

A common question from our users has been, “How do I set up a rolling deployment?” The basic challenge is to run some deployment process on a number of machines, but not all at the same time. One or two machines should be upgraded at a time while the rest continue to service requests using the previous deployed version.

The challenge with older AnthillPro versions

Doing things one or two at a time was supported in versions 3.3 – 3.5.x through iterations. The problem was that the number of iterations was completely fixed in those versions. So the rolling deployment workflow would either have to be replicated for each deployment environment or job preconditions would have to validate the iteration count against the number of machines in the environment. In other words, rolling deployments used to be doable, but a hassle.

The Solution in 3.6

AnthillPro 3.6 improves this situation dramatically. Iterations are now more closely linked with agent selection, and the iteration count can now be set to match the number of agents selected by the agent filter. Combined with iteration parallelism and caps, we can now easily configure something as sophisticated as “Run this job on all matching machines in the environment two at a time”. As one machine’s deployment completes, the next will begin.

To accomplish this, go to the workflow’s “Definition” tab, click on a job, and select “Iterate Job”. Then allow parallelism if more than one machine should be deployed at once, and enter your cap – in this case two deployments at once.

Once configured in this way, rolling deployments will happen consistently across the various deployment environments - whether a single machine in development test or dozens of machines in staging or production.

Increasingly, when we visit enterprise customers, we find organizations that are using or adopting Scrum. In conversations amongst our consultants, we’ve observed a natural affinity between the build server and the Scrum process. While the most critical piece of technology for the Scrum team is often an agile project management system, build and test automation can be a key to the success of a Scrum team by improving communication,  speeding testing, and identifying problems early.

Read more...