How should I approach Continuous Integration and .NET Framework Versions

生来就可爱ヽ(ⅴ<●) 提交于 2019-12-11 03:11:00

问题


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).



来源:https://stackoverflow.com/questions/423978/how-should-i-approach-continuous-integration-and-net-framework-versions

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!