Question

We have a distributed .net system which consists of several solutions, each with different configuration and deployment needs. Currently all the code is in one TFS project and each solution has its own build. These are configured to trigger for changes in that solutions source control folder.

We are moving to Team City, Git and rake (due to ease of branching and license costs) and so are reviewing the whole build process and have been unable to find good information on this. The issues we are struggling to resolve are:

1. Should we have separate builds or one large build? All the solutions need to be built and deployed for the system to function, but it is nice to have small builds as they are quick and easier to debug. Some solutions are more “stand alone” than others. Our current practice is mostly just to queue all the builds when we want to deploy to test or production environment, but sometimes we just queue an individual solution if that is all that has changed.

2. Should we store all the solutions in one repository or should we have a repository for each one? We use some shared projects and dlls, how would these work with separate repositories?

Answer 1

There are a lot of different ways to store repositories, perform builds and deploy instances. And many from them are right. From my practice it is not important what technique you use and what tool to make builds and deployment. So it is important to raise questions that affect these processes:

• to prevent messing of the solutions/projects that can be separated (as stand alone).
  If a project is shared between few solutions, then it would be better to create a separate repository for it. And just add relations from dependent solutions/projects to this;
• to prevent problems during generation of different builds for different purposes (Configuration Management in other words). You can adjust TeamCity for this (mostly for build and deploy automation after each ‘commit’ or time-based schedule), or use some simple but powerful utility like NAnt with predefined configurations.

So I see no reason to make one large build (only on release may be), but separate builds would be easier to use (for QA, and developers that work on some part only). The second issue is a time. For example, to make full build with all the projects in one solution it takes about 10 minutes on quad cpu 8gb ram, but to make a build with Accounting part or Enrollment part only it takes 1 minute – it does matter for me. Just try to imagine this process, draw on a piece of paper, and it become clear – what to do, and why do.

All opinion is based on my practice only, in well successful projects that experiencing changes every day/night and have dozens of configurations (your builds).