Summary
Motley: The best way to control build breaks is to slap around the responsible developer.
Maven: Continuous integration is an agile technique that minimizes daily build failures and minimizes integration problems in real-time.
______________________________
[Context: Motley is expressing some frustration that his team keeps breaking the daily build]
Motley: Damn! Yet another broken build last night. What is going on with this team? Lately we've had some really bad check-ins to source control causing issues with our daily build. The daily build is our lifeline here - if a build is broken that means a good portion of the team is blocked. ARRRRGGGHHH!
Maven: Calm down, bud. Why are the builds breaking?
Motley: Combination of things. Sometimes people are sloppy and forget to add a file to their source control change list. The build works locally on their machine, but once another machine syncs and builds, all hell breaks loose. Other times, it is obvious the developer has not run the unit test suite prior to check-in and there is a functionality break. A further problem is conflicting check-ins between developers causing havoc when the central build runs. In addition, there are times when the developer obviously has not run static analysis tools, which could have found a few problems even before check-in.
Maven: All common problems in many software companies. And all should be preventable.
Motley: I agree! It's just sloppiness and I am getting tired of it. You trust devs to do the right thing and it doesn't happen. Time for the hammer to come down.
Maven: Don't jump to conclusions just yet. Devs get put under lots of pressure to meet deadlines and periodically things get overlooked. What we need to do is put a system in place that helps them limit their mistakes without much in the proactive action relying on memory.
Motley: Me slapping them upside the head ought to be enough for them to remember!
Maven: The only time violence solves any problems is, well, I can't think of a scenario. Anyway, have you heard of "continuous integration"?
Motley: I'm not quite ready to live with my girlfriend, thank you very much.
Maven: Always the comedian! One recommended practice in agile development circles, most notably Extreme Programming, is continuous integration. The idea is that developers should be integrating their code together at regular intervals to head off build breaks before the daily build takes place. Leaving integration until the daily build happens or worse, until the end of a coding cycle, is a proven recipe for disaster.
Motley: I agree, in principle. But, how do you do it? Do I have to walk around and make sure syncs and builds happen on a regular basis?
Maven: Definitely not - tools to the rescue! One popular application in the .NET community is a free tool called CruiseControl.NET. You set it up on a server somewhere and have it monitor your source control system for check-ins. It works with many different types of source control systems, including Perforce, CVS, SourceSafe and others. Once a check-in happens, the server takes over and performs whatever actions you want it to - most notably, a sync and build of the complete system. You can even set it up to run other actions like a unit test suite, static analysis, or others.
Motley: Sweet! You mean once the server is set up it will do all of this on its own without manual intervention??
Maven: You bet! Individual developers can monitor the results by using either (a) a web site that they hit for integration status; (b) a Windows tray application that always indicates current build status (red icon = failure; green icon = successful run); or (c) an e-mail notification. It will track historical runs and tell you what change list triggered the run.
Motley: Oh, I must say, that is way cool! Now we don't have to babysit developers, and the code is being integrated constantly. That should definitely cut down on build breaks. How long does it take to set up?
Maven: All you need is a machine capable of performing builds, the CC.NET installation package, and an installation of IIS and ASP.NET if you want to use the web portal. Give it an hour or so to set up and you'll be off and running.
Motley: I am definitely going to try this out. It would be even cooler if Visual Studio had this kind of functionality built in.
Maven: Your wish is Microsoft's command! Visual Studio 2008 ("Orcas") Team Foundation Server supports continuous integration. You can specify a trigger for a build when you create a new build definition or modify an existing one. You can use on-demand builds, rolling builds, and continuous integration where each check-in starts a build. This all integrates with Visual Studio source control support.
Motley: Not bad, Mave. Now give me some more information on how I can get you out of my hair for a couple of hours so I can get this stuff implemented and communicated to the team.
Maven's Pointer: Continuous integration (CI) is quickly becoming a mandatory practice for all development shops. Risk of breaking the software is substantially decreased, and as a result, the team becomes more efficient by minimizing blockages due to build breaks. In addition, you integrate as you go and avoid the "big bang" integration at the end. Also, since build breaks flagged by a CI tool are immediate and generally tied to one or two changes to the source, it is easy to narrow down the problem and fix it.
Maven's Resources:
PingBack from http://hairgrowthproducts.info/story.php?id=4568