-
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…
-
Vanilla build server and a little NuGet gem
Vanilla build server is a concept that says that the build server should have as few dependencies as possible. It should be like vanilla ice cream without any raisins (I have raisins in ice cream). Let me cite the classic (from: Continuous Integration in .NET): “It’s strongly suggested that you dedicate a separate machine to act as the CI server. Why? Because a correctly created CI process should have as few dependencies as possible. This means your machine should be as vanilla as possible. For a .NET setup, it’s best to have only the operating system, the .NET framework, and probably the source control client. Some CI servers also need…