Totally agree.  I started in my current shop about 4 months ago and they didn't have a CI server setup.  Downloaded TeamCity and took a day to set it up on a old desktop.  It's caught so many bad checkins (forgot to check in the new project file,etc.) since then it's not even funny.

That has been my day one rant at new companies for a few years. So easy to set up for lots of benefit. It does often mean sorting out dependencies in existing builds though.

Worst thing I ever saw build wise was a 10 page build instructions document with dependency diagrams. It was a manual 1 day process to get an operable build of this system.

Rant on, man. When I do talks, I am still shocked at the number of people (or lack of) who have an automated build process. There are even some who still don't have source control of any kind. It makes me shudder. Keep fighting the good fight.

Lee

Completely agreed. There's Team City for FNH, and we use TFS at my day job. I can't imagine developing without it. How else do you know if the code you checked in will compile for the next new user that checks it out?

I agree; however, I don't believe CI is sufficient in and of itself. You also have to build a culture where a failed CI build is a priority. (Management buy-in helps.) I have seen a build server running for months with developers completely ignoring failures.

"How else do you know if the code you checked in will compile for the next new user that checks it out?"

You get latest before checking in?

@Derik - yes, you are technically correct, in theory.  In theory, you can have a brand new developer coming onto a project every day.  In practice, things are usually not so dynamic and exciting.

I'm not arguing against CI, just stating my opinion that in practice, it is actually far less crucial than is implied by its advocates (much like any flavor of the week practice).

For example:

"I’m sorry, but if your team does not care about the little details which make your product better what the hell makes you think you will get the big details right?"

If you stop and think about this sentence, it is actually complete nonsense.  So, if my team is not doing CI, then we will [therefore, probably] not get the big details right either?  

Trevor,

It's very easy to create a failed build. You've mentioned one, not getting the latest. Yes, you should get latest but the onus is on the developer to remember that. Another more common example: forgetting to add a library/class to source control. Or having a dependency on something that is installed in the GAC (or somewhere else) on your machine.

The major benefit of CI, in my world, is the shift in responsibility. If I get the latest version of the code and it doesn't compile or work, then I'm now responsible for investigating an issue I didn't cause. That means either fixing it or tracking down who caused it (and that person may have long gone for the day). In a CI environment, that responsibility is shifted back to the person who caused the error.

As Derik says, for the amount of effort it takes to set up, I almost consider it negligent not to.

I'm an advocate of CI. But how do you get a company to take this on when you are just a little grunt? Quit and go somewhere else?

I've always had an automated build, but never had a CI server. A couple weeks ago I setup an old workstation to be a QA box. At the end of every day I simply sit in front of it and perform the build and browse to the web application.

It's probably the most primitive form of CI because it's a manual process but even that simple task makes it easier to go home at night.

I only work in a team of 2 so we don't have the issues that a larger shop would have, but once the dev team is greater than 1 person this kind of process really comes in handy.

My next step is to install TeamCity.

I believe one of the biggest barrier to entry in CI for most people is trying to get it perfect. I personally feel it's best to start small. Make sure you can build from the command line without VS from a fresh checkout. Then automate your tests. Then automate a deployable artifact from your build, etc...

At my last employer, my friend and I started about the same time. We moved our team to CVS NT, NAnt and Anthill. This replaced a multi-hour semi-manual build process (previously code was built for each environment and each machine)

That caught so many missed check-ins and "works on my machine" excuses that it was a no-brainer to move on from there.

We then started using our build scripts to publish to a hand-off location for our deployment team.

From there, on to automated deployments (well, push-button deployments)

At the end of it all, we went from manual builds, forgotten check-ins and a general maintenance mess to automated builds, fully staged, and deployable to any environment in a consistent and automated manner. We never rolled back code because of a show-stopper bug or forgotten deployment step.

The largest issue, being a large corporate IT shop, was that we had to be careful to call our CI a "build workstation". Bbecause, if they ever heard it called a "build server" it would have been shipped to the data center and locked down.

@Gavin,

If your team is experiencing issues that you know can be directly fixed by a CI solution (be it something running locally, a workstation somewhere, whatever) then it should be a fairly simple sell to your boss. If you don't have any issues, then it's probably not necessary to bring up CI.

Recently I had a post where I made the statement ‘To CI or not to CI, did not realize it was still