Possible Duplicate:
How many developers before continuous integration becomes effective?

When does continuous integration (such as CruiseControl) add value to a project?
Do factors such as

  • Number of Unit Tests
  • How often changes are made
  • Branch development
  • Team Size

make a difference in the value added by continuous integration, or is it something that's always worth the trouble?


6 Answers 6


I think that it adds value even in a single person starting project. The earlier you set it up, the easier it is, and the less time you will have to spend during more crunch times worrying or wishing you had it.

Even from the start it will make sure that all unit tests (even if there is one) will get run as often as code is checked in. Otherwise you rely on yourself to run them each time, and you will forget.

In my experience it is so easy these days with CC.Net or Jenkins, etc. that it is not worth waiting. I put it close to the same level of necessity as source control.

Edit: At first you will be less continually "integrating" and more continually "building" but as more versions and people get involved, then it will be true continuous integration.

  • 1
    Agreed absolutely - right after File|New Project... whilst you're on, you want to sort out your deployment as well. The more capability you establish early on the better of you'll be.
    – Murph
    Commented May 19, 2011 at 19:45
  • For the same reason that it's easier to write a new class than refactor an existing one.
    – StuperUser
    Commented May 19, 2011 at 20:30

IMHO, it is always worth the trouble. Even if you don't have a single unit test and the integration is nothing more than checking out the project and building it you are still coming out ahead. If your CI build succeeds it means any idiot can check out your code and build it. This probably puts you ahead of 85% of software projects on planet earth.

I would also argue the value scales with the size of the project.

  • +1 to this and ale's answers, which are nicely complementary: the earlier you set CI up, the easier it is, and the bigger the project grows, the more valuable the CI becomes. Commented May 21, 2011 at 12:35

The gain depends on what you use it for. If you use tests you see if you break functionality etc., but regardless of this you always get one gain.

You know if the source code in the current state will build or not, because the robot built it from scratch.

If somebody broke it, you will learn so very quickly so it can be fixed.

That alone is worth a lot. All the rest is just extras.

  • 1
    So is the actual benefit of CI knowing if your build is stable? Since we don't use unit tests at all in my company, we find out a build is broken by somebody else trying to compile it and getting an error. If we had a CI server set up, we could know immediately because it would say the build failed? I doubt these guys even know what a CI Server is but that's a pain point we face regularly so I'm always thinking of a way to fix it. Commented May 19, 2011 at 18:44
  • 2
    You could claim that compilation is the first test of any unit. So, if it compiles, it passed the compilation test. Under that idea, even without unit tests I believe it is of great benefit.
    – ale
    Commented May 19, 2011 at 18:55
  • @wayne, yes, but you need version control too, for this to work well. When the build breaks, the id who checked in the commit who broke the build gets an email about it, so it can be fixed right away.
    – user1249
    Commented May 19, 2011 at 21:44
  • Yes, the basic benefit is knowing you can build your code. On two machines (the developer who checking it in and the build machine)
    – Мסž
    Commented May 20, 2011 at 1:02
  • @wayne, the basic reason is "know if your build is stable". The definition of stable, however, varies greatly from place to place. Some people consider a build unstable if any test fails.
    – user1249
    Commented May 20, 2011 at 9:11

Continuous integration only has as much value as your automated processes.

Your project should have a basis in solid automated AND repeatable processes. You should make sure the following are automated and deterministic:

  • test compilation and execution
  • source compilation (including documentation)
  • packaging (yes, packaging should be automated as well)
  • Number of Unit Tests
  • How often changes are made
  • Branch development
  • Team Size

These are all orthogonal to the potential value of a CI system. They may impact how you implement the system, how many resources it requires, but not value. That is because the value of the CI is in running your automated process often and automatically which drives errors our faster.


I think the number one pain that went away when I started using a build server was the just-before-the-release-panic where you learn all sorts of nitpicky details about what depenencies were never checked into source control, what projects stop compiling, what projects have tests that stop running, what recent changes broke the integration tests (the slow ones that actually hit the server or drive a web browser)

The time invested in using a build server (in my case, TeamCity), was paid back in the first release, easily.

-Number of Unit Tests

Well written unit tests execute in about the time it takes to compile & can be added as a post compilation step. So this isn't an argument for using builder server. The fact that devs don't usually set up unit tests as post compile step, is a good argument for it though. Also, if you have slow integration tests, a build server is happy to run these every night, overnight, but you won't get your investment in slow integration tests back unless a build server is running them for you-- people just don't manually kick of slow integration tests that often.

-How often changes are made

If the code changes infrequently, then I'll forget what unit test assemblies need to be run, etc, etc. If the code changes frequently, I'll want frequent compiles and test runs to make sure that I'm safely running with scissors (rapid changes = more human mistakes and the faster my build server can detect them for me, the faster I can run with scissors)

-Branch development

Before I had a source control, a build server, etc in place, I generally considered branching to be to much overhead to mentally keep track of anything. So I really don't know if it is easier or hard to do branch development w/o a build server. I think a team would be more likely to attempt branch development with a build server.

-Team Size

Having source control lets me be calm about devs checking in a disaster-- I can reverse it, but it is the build server that lets me find out about it, sometimes minutes or hours afterwards instead of weeks afterwards.


The value would scale with the size of the team and the project. It also scales with complexity. If you have different processes to run, such as unit tests, integration/system tests, static analysis, metrics generation, packaging, deployment, etc, the complexity of the processes increase. Automating these is a big gain, even if you are a team of one (like me) or work on a smaller project.

Not the answer you're looking for? Browse other questions tagged or ask your own question.