One of the things I stressed when I gave my CI talk last week was how important it is that when you set up your build process, that you make it self contained and under source control. One of my reasons was so that you can quickly get a build server up and running, but there's another reason for doing it that's probably even more important: Getting new developers ramped up. In the presentation, I used a fictitious example of how a developer typically gets ready to start on a new team:

1. Get latest.
2. It doesn't build.
3. Find needed third party libraries.
4. It doesn't build.
5. Oops, they got version 3.1 when they need version 3.0.1. Get correct version of third party libraries.
6. It doesn't build.
7. Figure out the last few configurations to get it to work.
8. It finally builds!

A couple of days later, they're finally able to build the code. It's not a real example, but it is typical. I picked two days because being able to go from 2 days to 10-15 minutes seemed like a huge difference to me - getting 16 hours of potential development time back can be a big deal. It's also about the amount of time to get a basic build process in place - you can justify integrating CI into your processes easily if it pays off after just one developer has to transition onto your project.

Anyway, I came across an example that's far more time than I accounted for. It's a series of emails going back and forth between a "newbie" and the project lead, who's too busy to really help the new guy out (sound familiar to anyone?). By the end, you find out the whole email exchange took two weeks - and the new developer wasn't able to start being productive until after that. Two weeks! That's a serious amount of lost productivity. And remember, this doesn't even include time to actually learn what the software is supposed to do.

If all of the necessary components had been under source control, it would have been a lot simpler:

1. Get latest.
2. Build software.

That's probably a little over simplified. You still need to document any configurations that are needed, but you could avoid the library version differences and database version differences. And you'd at least know exactly what libraries are part of the software.

So, again, is your software really checked in?