This Bamboo customer story is the third of an 8-part blog series about why so many developers adopt continuous integration, written by our guest blogger John Ferguson Smart.
John is a consultant and trainer specialising in Build Automation, Enterprise Java, Web Development, and Open Source technologies, currently based in Wellington, New Zealand.
Building in the dark
Ragnar, for example, 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..
Last time we talked about Aligning work habits; stay tuned for the next Bamboo customer story when we talk about driving quality with hyper complex distributed builds.
What’s your adoption story? Tweet Atlassian or leave a comment below about how and why you adopted CI.