CODEWITHSUNDEEP
asp.netbuild-processcontinuous-integrationcruisecontrol.net
Tim Peel
Tim Peel

Reputation: 2344

.NET automated build with cruisecontrol.net + nant - multiple assembly structure / best practice

I'm doing some work with several shared .NET assemblies and a generic web application that I would like to handle better in our CC.NET/NAnt build environment.

Currently, we have several .NET assemblies (shared common code that we use in client projects) that exist in different .NET solutions within different repositories in our SCM (Vault incidentally). They are all configured under CC.NET separately so we have a decent amount of control over their build and deployment at present.

We have developed a CMS system that uses some of the .NET assemblies and includes a common administration website project and a template website example project. Out of this one solution we have the following elements that need to managed separately:

I'd like the build output of this solution to be a Visual Studio template, which we can use to develop other client sites and better manage version changes within the CMS itself, as we add features to the codebase.

I have a rough approach for all this and think it is achievable, however, I wanted to open this topic up for discussion and see what everyone else is doing when it comes to managing the build and deployment of multiple solutions.

Main considerations for us are:

Hopefully this question isn't too vague and some of you will have dealt with these issues. Look forward to hearing everyones experiences.

Many thanks! Tim

Upvotes: 0

Views: 1727

Answers (1)

Steen
Steen

Reputation: 6849

I unfortunately cannot answer all of your points, but let me start with this one:

  • Do we make use of the integration queue functionality in CC.NET to ensure a build order and pull together the assemblies we need for the CMS at build time?

The short answer is -yes, you should. The queue attribute ensures a build order within the running instance of CC.NET and is gives you serialization of the builds that depend on each other. For specifying which projects depend on each other, you should use project triggers. Do not rely on the queuePriority for this task.

You shold most likely pull the pieces you need to do the build at build time. Unless you have some time constraints on your individual builds.

Re:

  • Developing and extending the CMS when it uses shared assemblies i.e. do we add the assembly projects to the trunk solution during development (across source control repositories) and then rely on the build to pull it together or do we use a different approach entirely?

I'm fundamentally against distributing binaries in the trunk unless it's some libraries that does not need to be updated/changed on a frequent basis. If you build the shared assemblies yourself, you should consider pulling them from the artifacts on the build server(s).

Upvotes: 1

Related Questions