from the perspective of a software developer and manager

Continuous Integration – Another Good Idea

Continuous Integration – Another Good Idea

A few posts ago, I spoke about using a version control system in order to provide you with several advantages while developing. The next piece of software that deserves attention is a Continuous Integration System. As with my version control post, we’ll first go over theory regarding why it is important and how it can be used. We’ll then go over some of the products available and end with a case study on one of my projects where my team reached the holy grail of development automation by combining a version control system with continuous integration.

The difficult part of writing about continuous integration is that there isn’t one logical place to start. Any one comment made about it would also be interrelated with 2 or 3 other ideas that each deserve their own piece of explanation. I’ll do my best.

At it’s simplest, a continuous integration tool is something that allows a team of developers to follow best practices regarding the integration and deployment of their code. When I say “allows,” I mean there are many decisions to be made and the initial setup is a very manual process. You have to decide on what “best practices” are for your team based on the language you develop in, your server setup and plans for the future. A continuous integration tool depends on having a couple other pieces of infrastructure already in place to be useful. One is a version control system, which we’ve discussed, and the other is a build tool, such as Ant, Maven, or MSBuild. I also want to mention that continuous integration has slightly less meaning in an environment where you are not compiling source code, such as PHP or Coldfusion, but can still be used to great effect there.

The setup effort can reward both the development team and the management team with things that they want. I’ll start with the developer’s point of view.

Automated Source Code Compilation. One of the biggest sources of frustration for a team working on a compiled product is a developer committing code that breaks the build. Continuous integration can be set up to watch the version control system for changes. Whenever a developer commits to the mainline, continuous integration will kick off a build. Continuous integration will report on the status of every build, and can be set up to send out emails with those reports. Build problems can be rectified immediately.

Automated Unit Testing. If the development team is using test driven development, the continuous integration system can be set up to run those unit tests automatically. Developers can know if someone on their team modified code that caused test to fail. The developer and the commit can be identified and the situation can be rectified before it becomes a large problem.

Automated Deployment. In addition to compilation, the continuous integration system can be set up to push compiled code and other necessary assets out to a server. This is where the rubber can really hit the road and save you a ton of time. Ideally, you’ll want your automated system to push to a development or integration box first where developers can test that their code works with the code of everyone else on their team. Next, the CI server can push it out to the staging or UAT (User Acceptance Testing) environment. This is where the QA and management team can verify requirement completeness/correctness. Lastly, the CI server can push it out to the production environment. This can all happen in an automated fashion without the developer needing to babysit.

Next, there are some benefits that managers get.

Happy Developers. Developers get to spend their time managing coding on the problem domain instead of spending their time babysitting deployments. Developers like to solve problems, but generally not organizational problems or problems that have been solved time and time again. In general, developers also don’t want to participate in processes fraught with the possibilities of human error. There’s always a bit of trepidation before a manual production deployment.

Increased ROI. Automation saves time and money. Many factories across the US have replaced much of their human workforce with an automated workforce. Regarding continuous integration tools, a setup time of 2 or 3 developer days and some minor maintenance can save developer weeks or months over the course of the year. And what manager wouldn’t be happy to get a bonus due to the increased productivity of their staff?

Error Reduction. If you have a 10 or 12 step production deployment process (which I have participated in before, so it’s not out of the question), there’s a huge possibility of human error on one of those steps. Automating that process gives you consistency and virtually removes all possibility of error from the process. Consistency regarding production pushes makes clients happy, which increase sales, etc.

Automated reporting. Continuous Integration tools can give managers additional insight into development status, deployment status, and whether something may need their attention. If one particular developer continually breaks the build, you may need to get them additional training, help, support, etc. Conversely, if a particular developer never breaks the build, you can reward him/her. Additionally, these systems can give you the insight you need to report to clients without having to have numerous staff meetings or questions to figure out the status of a particular project.

If you haven’t guessed yet, I am a huge fan of continuous integration systems due to the many benefits they provide at a relatively low overhead and maintenance. In the next article, I’ll be looking into specific tools available and under which situations you may want to use them. I’ll also touch on the correct server and development computer setup to make maximum use of the technology.