Most people don't need an introduction to Continuous Integration (CI), but there are still many programmers and teams out there who haven't adopted this practice. I know some of them personally. This writeup is for them. It is a series of short and hopefully persuasive arguments for adopting CI. The idea here is to give the adopter a variety of easy to digest reasons for using CI.First, here is a brief definition for CI. Continuous Integration is automated compilation and testing that leads to the creation of ready to deploy software any time the code base changes. Now for the arguments.
The Code you Can't Deploy Argument
Code you can't deploy is useless code. You just put the finishing touches on a servlet six months in the making. Good thing too because the customer plans to go live this weekend. It works fine when deployed on your windows workstation from Eclipse, but the customer is deploying into a clustered environment with a Linux operating system. Guess what, it is going to be a looong weekend. Had you been using proper Continuous Integration you could tell your client with confidence that there wouldn't be any big surprises.The Cost and Quality Argument
One of the basic operations of writing software is integration. As a developer you constantly integrate with external systems, libraries, teammates' code, even the code you wrote yesterday. Programmers are natural continuous integrators! But programmers are only human, and we make mistakes (better known as bugs). CI, done properly, is a foolproof way for rapidly discovering bugs. And the faster we discover a bug, the cheaper and less risky the fix. CI makes our software higher quality and lower cost.The Nobody's Perfect Argument
Good programmer writes a test and the code to make the test pass. Next, good programmer runs all the tests, not just the tests around the change, and only after the tests pass does good programmer check in. Why bother with a continuous integration server like CruiseControl when everyone on your team is such a good programmer? Hmm, wait a minute, did good programmer remember to check in that 3rd party lib? Did good programmer forget to do an svn add on that new unit test for that critical 3rd party interface? Even good programmers make mistakes that can be troublesome for the rest of the team and costly down the road. Really good programmers know they make mistakes and love Continuous Integration for catching those mistakes before they impact the team and the project.The Dependent Projects Argument
Team one has a build. Team two's build depends on what team one is building. Team one creates a new drop of their system once a week for delivering to team two. This means it might take up to a week for team two to realize that team one has broken their software. Perhaps it takes another week for team one to understand and fix what they broke. Meanwhile team two is building against the last working drop they recieved from team one, which is now three weeks old! This whole mess would have been avoided had teams one and two been using Continuous Integration (CI). With CI team one is automatically creating a new drop of their system every time their code changes, and team two is automatically testing their code against team one's latest drop. Now both teams know within minutes of checking in when and why their software no longer works.The Better Communication Argument
A Continuous Integration (CI) server like CruiseControl gives developers a centralized place to see the status of the code. They can see which classes their team members are working on, grab the latest deployable, and get notifications when the status of the build changes. This information can be a catalyst for important project conversations. One developer might notice that another has been checking in code without tests. That is a good time for a quick talk about the importance of unit testing. Two developers might realize they are working on the same part of the system, another opportune moment to talk about how they might avoid commit conflicts . CI increases the points of contact between individual developers or pairs during the day and encourages, even forces, better team communication which can head off costly problems before they have a chance to arise.It is difficult to leave it at that. I still want to give more examples, discuss all the different levels to which you can take CI, and talk about how even small projects and small or single developer teams can benefit, but so much has already been written, so I'll conserve space on the web by just linking to a couple good sources for further reading.
No comments:
Post a Comment