Some co-workers and myself are tasked with a "rewrite" of an ancient, unmaintainable application and to shape it into something workable.

I am setting up a continuous integration server, and since we are developing for .NET, I think I will use CruiseControl.net

The software being built will have a large amount of build targets (language, features, etc), so changes to the build server config might be more on the frequent side. Since they'll also include drivers and will run a suite of QA tests, they might get pretty complicated too.

So one question I have, is should I put the configuration files and settings for the build server in the same source repository as the code base. Then it's easy to know what version of build configuration was used with a revision of the code base. But something about that seems kind of "icky" to me but I don't know why.

Or, I can have a separate repository or location for the build server configuration, and maintain the lineage of the config relative to the main code base with the commit messages.

Does anyone have any familiarity with either situation and did you run into problems doing one or the other? I believe CC.NET can automatically check out its config info, so both options should work.

  • use Hudson/Jenkins. The ease of config is such that you'll thank me for it later.
    – gbjbaanb
    Commented Aug 6, 2011 at 14:13

1 Answer 1


In my work we keep them both together.

I think that as a design you would generally prefer to have everything required to compile-test and package your project in the same repository.

The big advantage of a CI server is that a commit which triggers some test failure is caught quickly and fixed by the developer. For this to happen the developer will need to reproduce the test locally, so it makes sense to keep it all in one place. It also makes sense for testing to be in the same location as the source as you would often develop some new feature and write the tests for it at the same time.

Apart from that, it depends what your CI server is actually doing. I would not keep any of the configurations required for the test in the CruiseControl configuration file.

Instead use some build tool (see question here) such as NAnt and maintain all the scripts required for building and testing in the repository.

So a "clean" project will have some main build file (let's assume it's NAnt), and you would build it with ant build, test it with ant test and package it with ant package. your CI server is only ever aware of the main build.xml file and its own configuration (the cruisecontrol.xml) should seldom change.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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