A twisted, yet valid observation

Today, I again saw what is an all too frequent occurence in some dev shops - a failed build.

Rather, a grossly negligent failed build. One that could have easily been avoided. So to that developer, and others of similar ilk, I send this message:

I know you only changed one line in a single file. And I'm aware it takes ten minutes to build the solution on your machine. I even realize that no one was going to pull down code at that precise moment.

Nothing, however, pains the resident Build Guy more than that big red Build Failed icon. Every time I see that, a little piece of me dies.

And no, Fellow-Programmer-Who-Shall-Remain-Nameless, remembering to build immediately after checking in the file is not "close enough." Sure you'll have the fix checked in even as the build reports the failure. And sure, any other time of the day I would have been wandering the halls and never would have known. But apologies won't help. It's still too little, too late. It's like applying the brakes after running over the cat...

Single responsibility builds

When I joined my current project, the CI build server (CC.Net) was already in place. For the most part, things were in working order. One item I took exception to was the fact that every build copied files to the development server. The idea being that a developer can run tests to verify that all of the pieces are working correctly. For most of the team, however, this is instead used as a convenient way to code the UI without running the services locally. This makes sense.

The problem, however, comes in when a significant change is made to that code (as in the recent data access changes.) Much of the code still has bugs to work out, despite the fact that the code compiles. The way the build is set up, the copies to the server happen after the compile, regardless of the unit test results. The end result is that after the change, developers could no longer test against the server's build.

Ideally, the continuous build process would not touch the dev server files. Instead, a separate build is created to copy the files on demand (using a Force Build in CC.Net.) When the build is in a faulty state, UI developers can continue working off a known-good base, while others can iron out the bugs in the server code. Another option would be to fail the build if any unit tests fail, so the file copies aren't carried out. Of course, this assumes the tests normally pass.

Continuous Integration = Consistently Compileable Code

*Note: This is a continuation of my previous post

"Now that we have basic SS usage defined, where does CC.Net fit into the picture?" Simple - it's what makes sure the code is in a usable state at all times.

Let's say you've finished creating the xml logger and checked everything in. But say you forget to check in one file. Everything builds on your machine, so you don't see the problem. You're pulled from the project and another dev comes in later to continue. Only, when he gets latest and attempts a compile, he receives a number of build errors. Now he wastes time tracking down the cause of the problem - a missing or outdated file - and who might have that file. Maybe you have the file, and he's wasted fifteen minutes. But say you no longer have that file. Now your colleague wasted that time, only to find out someone will have to recreate the work.

Say instead you are working on code at the same time as another dev. His job is to create the data and business layers, while you focus on the front end. Somewhere during development, your colleague decides to modify a few method signatures. Methods that you happen to be using. And your colleague fails to warn you. At some point you'll get latest, only to find that you can no longer compile your code. It's likely that both of you must stop what you are working on and get the build back into a good state. If there are only two of you, it might take twenty minutes. As the number of devs on a project increases, the time required to restabilize the code likewise increases.

I previously worked on a project that had over a dozen developers. Due somewhat to poor architecture, a break anywhere caused problems for the entire team. The choices were to get latest and spend the morning stabilizing the build, or using outdated code, which meant integration later became even more difficult.

Fortunately, these problems are easy to address using CruiseControl.Net. Its job is to monitor the source code repository for any changes. As soon as a change is made, CC.Net gets latest and rebuilds the code. If the compile fails, everyone on the team is immediately (within a few minutes anyway) notified of the failure. The dev who checked in the broken code can address the problem, and other team members know not to get latest for the moment.

Regarding a broken build - if you aren't working on a fix, stay away from the repository. Getting latest means the code on your box will no longer compile. Checking in code may make things worse. It's best to fix one build break before possibly introducing another.

One more thing - if you break the build, fixing it should be your top priority. If you check in code at the end of the day, hang around to verify the build is still good. If you're in a hurry and can't wait for the build, don't check in the code. You're more likely to forget something in your haste, increasing the odds of a break.