How should I approach Continuous Integration and .

问题:

I am just beginning the move to the .NET Framework 3.5. I use CruiseControl.NET for our Continuous Integration and would like to know how other people approach setting this up.

I have a branch of the source code entitled NET3.5 but for now am keeping the trunk as 2.0.

I have created two CruiseControl projects that checkout from the trunk and the branch.

So I have two continuous integration projects even though there is only one code base.

I think this is the correct approach because I need to use different versions of the aspnet_merge.exe to compile the code which means two separate configuration files and thus the two continuous integration projects.

Is this approach OK, should each branch be built separately or should it just be one big code base that compiles different release versions in one giant build?

Cheers

回答1:

Personally I create a new CCNet project for branches, which sounds like what you've done.

The benefits of this are:

• Changes in one branch only cause one project to rebuild
• You have seperate build reports/artifacts for each branch
• If one branch breaks, the other branch can still be built/deployed

When you merge the branch back into the trunk, then you can remove the extra Cruise project.

Let me know if there's something specific to your ASP.NET application that I've missed here.

回答2:

Switch to TeamCity and have multiple builds (at least one per branch). It's very easy to configure builds in TeamCity, and this is definitely the right solution to testing different versions of your codebase (framework included).