3

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 i.e. 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

puneet
  • 769
  • 1
  • 9
  • 34
  • Is the question refering to that you have your application installed on a server, then you want to update the .DLL files automatically should there be a change in version number? If so is it possible to get the assemblies which are output from your continuous builds into a single folder then I can have a look at posting you a solution :) – LukeHennerley Sep 03 '12 at 13:14
  • no the deploying task is done by a script which just puts the patch in the ftp and the remote servers automatically downloads any new patch and apply them. If you have some better idea by any other means we can implement it instead of the script – puneet Sep 03 '12 at 13:17
  • That is exactly what I want to do. Create the patches by finding which dlls have changed since the last build and putting them in a predefined directory structure. – puneet Sep 03 '12 at 13:18
  • So you will have a predefined directory structure (target). Where abouts will your source files be held? Would it be possible that they could be in another folder? Just trying to get some loose ends tied together on my part – LukeHennerley Sep 03 '12 at 13:31
  • yes the source files are in working directory which is checked out with svn. when I build it we get the build inside the bin folder in the source. Then I make a release from all the startup apps for the QA. But I can not forward the whole release which is big in size to the production servers and also they have client specific config files. So I want to make a patch which is similar to the directory structure of the release. So that I can copy it to the production server only the files which were changed. The bin folders of all the 6 solutions when combined make a release. – puneet Sep 03 '12 at 16:03
  • Have you been through this? http://stackoverflow.com/questions/6260383/how-to-get-list-of-changed-files-since-last-build-in-jenkins-hudson – Sandeep Sep 04 '12 at 07:09

3 Answers3

3

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!

skolima
  • 31,963
  • 27
  • 115
  • 151
1

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 - I.e. 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) - I.e. Souce file locations, references etc.

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

Simon Laing
  • 1,194
  • 7
  • 18
  • we have implemented the above method and it is working fine. We just need to be careful that the patches are made for all the update. We are now trying to make the ccnet update only 1 revision at a time so that we have individual patches for individual revisions. – puneet Sep 11 '12 at 04:38
0

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.

JoeBilly
  • 3,057
  • 29
  • 35