Posted by johnsmart
on April 16, 2009 at 1:27 PM PDT
This case study is the third of an 8-part blog series about why so many developers adopt continuous integration , and originally published on the Atlassian blogs .
Ragnar is principle consultant at an Icelandic internet development firm based in ReykjavÃk. He and his team develop web applications for a variety of clients, primarily using PHP. Application source code is stored in a Subversion repository. Applications are typically deployed to three different servers: a local development server, a staging server that the client can use to preview the application during development, and finally the live server. Before adopting a Continuous Integration system, people struggled to keep the code repositories synchronized with each server.
The deployment process was largely manual - they had to manually commit to the repository and then manually deploy the code to the various servers at the appropriate times. This manual system was slow and error prone. It was easy to accidentally deploy code to the wrong server, or to deploy the wrong code. Indeed, before the CI system was installed, developers sometimes fell into the bad habit of deploying new code directly to the live server before testing it. This tended to happen most in situations where time was a critical factor and the client was putting the team under pressure to deliver. However, this was a false economy and very often, the code would have a few minor issues that normally the client would never have seen.
Making the change
Ragnar wanted a system to automatically deploy the right code to the right server at the right time on each commit to the Subversion repository. So Ragnar set up a CI server to monitor all of the various code repositories . He configured it to deploy any newly committed code to the development and staging servers automatically on each new commit. On each build, an Ant script uses SCP to securely transfer the code to the servers. But he didn't want untested code going live, so he kept deployment to the live servers as a manual task.
Clever Notification Strategy
Once this was set up, he needed a notification system for the developers to keep them up to date on all the new deployments for their various projects. All staff members use instant messaging (IM) extensively for internal communication and collaboration, so it seemed an obvious choice for their primary notification strategy. Ragnar set up a public IM account specifically for the CI server. This way, after every build, engineers are automatically notified of it immediately via their IM client . With one of their current projects, for example, they are collaborating with another software company on the development. The IM notifications keep them informed of any new builds that they have triggered, allowing them to talk back to the CI server and collaborate with the team . Without this notification system they would have to manually check the comments in the repository to see what they had changed. Now, it's all automatically sent to them via IM.
Ragnar improvised his own "information radiator", a concept frequently found in Agile circles. According to Agile guru Alistair Cockburn , an information radiator "is a display posted in a place where people can see it as they work or walk by. It shows readers information they care about without having to ask anyone a question. This means more communication with fewer interruptions." In many Agile projects, information radiators take the form of graphs, charts or diagrams, drawn up on very large sheets of paper and stuck on a prominent wall in the team's working area. For a Continuous Integration server, Lava Lamps are sometimes used for this purpose - the lamp bubbles green if the builds are successful, or red if there are build failures. However, you don't always need to go to such lengths to get an effective CI information radiator: a strategically placed LCD screen can be just as good. The bigger the better, obviously, but even an old 17 inch flat screen display is better than nothing.
Check out how one of the Atlassian teams does it..
"Probably the best training course I've been on."..."Not just how to write Java code but the 'business end' - how to build, test, deploy, manage and monitor"..."One of the best and most useful courses I have attended. And they didn't even try to sell me anything!" - Coming soon to London! Get up to scratch with the latest in Java tools and best practices! Sign up on the 2009 season of the Java Power Tools Bootcamps.