Hi Is that not a bit of overkill? I mean : why only replace 3 dlls of the current X
Unless of course the total patch-package is somewhat big (let's say 50MB) why not just replace all dlls when all is ok? now you're testing if a fix is ok --> good but you're also creating patches, and so you have to re-test the entire thing, which is at least double the effort. I would replace all dll's in the patch But to give you some idea's : <quote> The way we are trying to create the patches is we are searching the logs of svn to find which files have changed. </quote> these are just the modifications, so you could use the modifications detected by CCNet of the QA project. situation : bug detected ° developer fixes it, resulting in 20 checkins ° QA merges those files into QA-repo QA tests it : fails ° developer fixes again, resulting in 10 more checkins ° QA merges those files into QA-repo QA tests it : ok now you have to create a patch of the dlls that were affected by those checkins of the QA-repo. I just took a part of a changelog of CCNet itself Modified rubenwillems project/CCTrayLib/Presentation/About.cs Modified RubenWillems project/CCTrayLib/Presentation/About.cs Modified RubenWillems project/UnitTests/IntegrationTests/TaskTests.cs Modified RubenWillems project/UnitTests/UnitTests.csproj Added RubenWillems project/UnitTests/resources/IntegrationScenarios/Nant.Build Added RubenWillems project/UnitTests/resources/IntegrationScenarios/NantAndExecTestMultiLineBuildArgs.xml Modified RubenWillems project/console/console.csproj These files where changed, if you could easily map this to the bin folders you're ok. In a QA environment this should be rather easy, I doubt that there will be a lot of adding/removing projects. In case of CCNet, if the modification starts with project/console/ the CCNet.exe should be updated But you have a bigger problem at hand : you must remember all changed files till QA is green, not only the last one. if your QA strategy is the following : in patch X we fix bugs A, B, C, you could use the modification writer to keep a track of all changed files till QA is back green / you release http://www.cruisecontrolnet.org/projects/ccnet/wiki/Modification_Reader_Task that makes it maybe easier to keep a track of the changed files / projects when you start a new QA cycle, be sure to delete that file holding all modifications :-) with kind regards Ruben Willems On 3 September 2012 15:23, pke <[email protected]> wrote: > 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 >
