SVN
-
Scaling CI–switching poll to push
Scaling CI has many flavors. For example: When: Code base / test no. increases -> build time increases, Teams grow, No. of projects grows. Then: Create targeted builds (dev build, qa build), Write fast unit tests, Smaller teams with local integration servers, Modularize the code base: Scale hardware, Add more build agents, Parallelize. and last but not least: Ease the source control system. Let me show you how to make Subversion and (TFS) Git pro actively inform Jenkins CI about changes in source control. The most straight forward way to let the CI server know that something changed in the repository is to configure polling. What it means is that…
-
Keep your lib folder up to date
I’m keeping all the 3rd party assemblies that I use in my .NET projects in a separate library folder called lib. It is a part of my Subversion repository. In most of my project it is placed in linked repository (with svn:externals property). It lets my check out the whole project on any machine I like and it compiles right away. But be aware! In such scenario (and, well… in any other scenario as well) you have to keep your lib up to date. Take a look at this nasty bug. I was using the NUnit version 2.4.6.0 Take a look at this test method: [NUnit.Framework.Test] public void Test() {…
-
Multiple projects – multiple repositories
Do you have one project you want to share between multiple solutions? Something like a big set of helpers or a framework you need here and there? There are multiple ways ones have achieved this goal. Let me describe how I’ve done this. We work with Visual Studio as our main development environment and Subversion as our source control system. What we needed was a systematic approach where we share our framework across all of our projects. We are actively developing our framework so simple dll reference is not an option. Our rules according to framework development make it fairly save to share the same code across multiple projects and…