Automatic patch building and deployment of .NET application

Question

The question in short form and then the explanation We want to create patches and include only files which have changed in the build due to some bugfixes for a dotnet application. The patches should get automatically built in the Continuous Integration process involving SVN, Cruisecontrol.net and msbuild.

We have a scenario here: We want to maintain a .net application which runs on remote servers using continuous integration. The source code is in a SVN and has 3 different repositories for DEV, QA and PROD. Our developers do new bug fixes almost everyday and merge the changes into the dev repository after their initial testing and satisfaction. The code after a certain problem is solved or a feature has been added is then merged into the QA repository. The QA code is built and tested on QA machines manually. After the QA testing we merge it into PROD. With it the QA also makes new patches for the files which have to be replaced or changed manually. Then the patches are deployed on a staging server. On which it is tested until perfect and then the patches are deployed on actual remote servers.

In search of continuous integration we are now trying to use a mix of CruiseControl.net and msbuild to do the process. The process is good until the stage where we have to generate patches from the QA builds automatically . After the patches are generated we will put them on a ftp server and from their they will be downloaded to the staging server to be tested. The problem ie the generation of patches from the new build has a few aspects. The solution file for the application has many projects and the dlls are copied using postbuild events to the startup app bin folder. So we have a specific directory structure in the actual application which itself is a combination of 6 solutions which are more or less independent of each other.

The way we are trying to create the patches is we are searching the logs of svn to find which files have changed. Then we are parsing it finding the project name. Then we are copying all the files from the bin directory of that project to the patch folder in the specific manner in which the release has them by using a mapping file which has all the files of the application in it.

So can anyone please suggest a much better or easier way to make a patch provided we have svn and the cruisecontrol.net. Or any other opensource tool to do that.

hope the problem is clear

Answer 1

This whole process, in general, goes against established best practices. This is not necessarily a bad thing if you have good reasons for it, but I don't see them here.

In essence, you are not using QA and DEV environments to secure the stability of production. Worse, you use different source trees to build code for them. This introduces new points of possible failures into the deployment process.

A standard way of approaching this would be to have a single SVN code tree - tag a version when it is released to QA (using already built binaries!), possibly tag it again when releasing to PROD. Don't re-build the binaries, use the ones that you actually tested!

Answer 2

If your Msbuild task is performing a build instead of a rebuild then the date/time of unaffected dlls will not have their modified date changed.

I would suggest this for the following reasons:

• Msbuild will update the modified date for any assembly which has been affected by a change - Ie an interface change?
• the assembly is what you want to deploy, so check this rather than the source for modifications. Otherwise you need to know the build process (won't change) - Ie Souce file locations, references etc.

Your deployment would just include the dlls from the build directories where the modified date >= BuildDate.

Answer 3

I agree with skolima about the recommanded build & patch process. You should create your patches from your initial tags plus the modifications and then create a new version which have to be deployed in all environments.

In my company, we are using this method :

1. Each successfull build are automatically tagged by our CI Server
2. When a patch is needed for a specific version, the programmers copy & check-out the tagged version and apply fixes on it
3. Then we have a specific "Patch" build on our CI Server which do exactly the same thing as a normal build with a "Patch" flag and point to the patched sources

The deployment target is the same, the build process is the same, only sources changes.

The plus is the patches have their own build history on the CI because they are builded separately but are treated as normal builds.

Anyway, if you want to automate a patching processes between two repositories via your CI, ihmo you have to create specific MSBuild tasks to do this. You can either try to merge the changes between them or check the SVN diff & patch commands.