Chapter 3. Continuous Integration

Continuous Integration is central to Continuous Delivery. Many organizations assume that they are “doing CI” if they run a CI Server (see below), but good CI is a well-defined set of approaches and good practices, not a tool. We integrate continuously in order to find code conflicts as soon as possible. That is, by doing Continuous Integration, we explicitly expect to hit small snags with merges or component interactions on a regular basis. However, because we are integrating continuously (many times every day), the size and complexity of these conflicts or incompatibilities are small, and each problem is usually easy to correct. We use a CI server to coordinate steps for a build process by triggering other tools or scripts that undertake the actual compilation and linking activities. By separating the build tasks into scripts, we are able to reuse the same build steps on the CI server as on our developer workstations, giving us greater consistency for our builds.

In this chapter, we first look at some commonly used CI servers for Windows and .NET and their strengths and weaknesses. We then cover some options for driving .NET builds both from the command line and from CI servers.

CI Servers for Windows and .NET

Although CI is a practice or mindset, we can use a CI server to help us do some heavy lifting. Several CI servers have dedicated Windows and .NET support, and each has different strengths. Whichever CI server you choose, ensure that you ...

Get Continuous Delivery with Windows and .NET now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.