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
make a difference in the value added by continuous integration, or is it something that's always worth the trouble?
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.
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.
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.
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:
- 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.
