It looks as if this may have been posted a while ago, but very useful nonetheless. It’s called 34 signs that continuous integration isn’t working. I understand why it was entitled this, but I think the title is a bit misleading. I think a better title may be: “34 symptoms that you might need (effective) Continuous Integration”. The article is almost like a list of smells that indicate you may need a better way to integrate your changes. I’ve identified some of the practices we describe in the Continuous Integration book to combat these “smells”.

Here are some great ones:

1. Everyone has a different set of projects checked out on their PC (Perform Single Command Builds, Centralize Software Assets)
2. You don’t have a master build script that builds everything on any (workstation) (Automate Builds, Centralize Software Assets)
3. You sometimes check in without catching up with other people’s changes (Run Private Builds)
4. You hate/fear checking code in (Commit Code Frequently)
5. It’s difficult to take a (’cut’) of the code that’s consistent enough to make a release… (Perform Single Command Builds, Centralize Software Assets)
6. It takes forever to make a release
7. Things that were working fine suddenly stop working (Perform Single Command Builds)
8. If you want to know what code is running live, you checksum or diff it against known versions (Build for Any Environment)
9. The code works in development and pre-production, but not in production or test (Build for Any Environment)
10. You are only allowed to release in the middle of the night/weekend/both (Release Working Software Any Time, Any Place)
11. Releasing a one-line fix for a show-stopping production bug is “too risky” (Label Each Build, Label a Repository’s Assets)
12. You often check in only some of the changed files in your workspace

Finally! After over two years, I got to see the results of my work today. We live in a world of bits and bytes and, of course, I’ve already seen the book in PDF form. But, there is something about holding the paper copy that is exhilarating. This is an advance copy I received from my publisher. It will be available to everyone else in about a week. 5,000 copies are being shipped to a warehouse as I write. They’re selling fast, so order your copy now.

Videocast demonstrating the first of the 46 practices in the book, Build Software with Every Change. This five-minute video uses CruiseControl, Ant and Subversion to demonstrate the processes involved in this important practice. The video has sound, so “turn them headphones up! Turn ‘em up. Turn them s#$%’s up!” (I will send a free copy of the Continuous Integration book to the first person to name that reference.)

The company I work for, Stelligent, is hosting a “Share Your Continuous Integration War Stories” wine and cheese event at our offices in Reston, VA on Thursday, June 28th from 5:30PM - 7:00PM. You need to RSVP, so respond soon because space is limited. We are raffling off the first signed copy of the Continuous Integration book at the event.

The Continuous Integration book is available online on Safari at http://safari.informit.com/9780321336385. You can preview it or enroll in the Safari service to view the entire book online.

In a recent post of the future of Continuous Integration , I pondered how the broken build can affect your development team and offered potential solutions. My next topic is what many consider to be the bane of CI, Long-Running Builds. Again, I don’t think there’s a silver bullet answer to this conundrum. But, depending on how the problem manifests, there are some solutions. I spend quite a bit of time in chapter 4 discussing long-running builds, so this is a quick synopsis.

The Problem

• In the context of CI, long-running builds can slow developers from moving onto their next task. For instance, on Agile projects, many employ the rule that you don’t work on your next development task until the integration build is successful

How Long is too Long?

• Well, it depends! Kent Beck suggests in Extreme Programming Explained, 2nd edition, that an (integration build) shouldn’t take any more than ten minutes.

Symptoms

• The obvious: developers complaining about how long it takes for the builds to run
• Developers check in their code less often (making integrations more painful when they do happen)
• People sitting around waiting for the integration build to complete

Possible Solutions

First, as I describe in the book , it’s useful to know what the actual problem is. From my experience, I’ve found that long-running tests are often the cause for a “long-running build”.

• Add some horsepower - Increase your CPU speed, disk speed, and/or your RAM. This is often a cost-effective and quick solution to the problem.
• Stage your Builds - Run a quick commit build that consists of compilation, fast-running automated tests (i.e. unit tests without heavy dependencies), and deployment. After this commit build succeeds, run a slower-running tests, full database integration, inspections, and installation (depending on your build)
• Categorize your Tests - Segment your unit, component, system, functional, etc. tests so that you can run them at different frequencies
• Run Tasks in Parallel - Run certain build tasks in parallel - such as tests. This can only work if the result status of one task is mutually exclusive to another

As I mentioned, this is only a high-level view on a difficult problem. There’s a lot more detail in the book addressing this issue. Depending on the situation, there are simpler and more difficult solutions than others.

Below, is a list of tools for running automated inspections (static and dynamic analysis) for the Java platform:

• PMD - verify code is adhering to the project’s coding standards
• CheckStyle - verify code is adhering to the project’s coding standards
• CPD - Copy Paste Detector (part of PMD project)
• Simian - Similarity Analyzer
• JDepend - Object-oriented metrics for determining robustness of the architecture
• JavaNCSS - tool for measuring cyclomatic complexity
• SourceMonitor - tool for measuring cyclomatic complexity and general code metrics
• Metrics - Eclipse plugin for gathering many types of code metrics
• Coverlipse - code coverage tool for Eclipse
• JDepend4Eclipse - JDepend plugin for Eclipse
• Cobertura - Code Coverage tool
• FindBugs - code metrics and analysis tool. Provides more advanced metrics than the “average” static analysis tools such as security warnings, etc.

In chapter 7, Continuous Inspection, we cover the practices, tools and techniques for discovering potential defects in your software.

In Chapter 6, Andy covers practices for automated testing tools. He uses plenty of examples for the Java and .NET platforms. Below, is a list of developer testing tools for .NET:

• NUnit - unit testing tool for .NET
• NMock - Dynamic mock object library for .NET
• NUnitASP - tool for automatically testing ASP.NET web pages.
• NDbUnit - seed your database to assist in component testing
• Selenium - Web-based functional testing that is cross browser
• Watir - Web-based functional testing for Internet Explorer

The problem with using an IDE as the sole means to build your software (i.e. on your integration build machine) is that it’s unlikely your IDE will be deployed into production (or at least it shouldn’t be). One of the themes I visit in chapter 2 of the book is that of reducing assumptions (risks or whatever you want to call them). Many of the IDEs wrap everything but the kitchen sink into them (I won’t name any names), so if you assume that the particular files and configuration provided by the IDE are there, you are setting yourself up for problems. If you can’t script your build, be ready to debug problems right before you’re ready to release into production…or worse, when your users are using the software. As a developer, use your IDE to execute your automated build. However, your automated build should have no dependencies with your IDE.

I interviewed Levent Gurses of Stelligent (the company I work for) over on Test Early in a vidcast where he gave a preview of his upcoming talk on code quality plugins for Eclipse that he is doing at the Better Software Conference in Las Vegas next week. He also blogged several times on the topic at Test Early providing detailed tutorials on JDepend4Eclipse, Coverlipse, CheckStyle, CheckStyle and Metrics plugins.