Wyyme Technology Junction: Continuous Integration

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.

By integrating regularly, you can detect errors quickly, and locate them more easily.

Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day. It was first named and proposed as part of extreme programming (XP). Its main aim is to prevent integration problems, referred to as "integration hell" in early descriptions of XP. CI can be seen as an intensification of practices of periodic integration advocated by earlier published methods of incremental and iterative software development, such as the Booch method. CI isn't universally accepted as an improvement over frequent integration, so it is important to distinguish between the two as there is disagreement about the virtues of each.^{[citation needed]}

CI was originally intended to be used in combination with automated unit tests written through the practices of test-driven development. Initially this was conceived of as running all unit tests and verifying they all passed before committing to the mainline. This helps avoid one developer's work in progress breaking another developer's copy. If necessary, partially complete features can be disabled before committing using feature toggles.

Later elaborations of the concept introduced build servers, which automatically run the unit tests periodically or even after every commit and report the results to the developers. The use of build servers (not necessarily running unit tests) had already been practised by some teams outside the XP community. Nowadays, many organisations have adopted CI without adopting all of XP.

In addition to automated unit tests, organisations using CI typically use a build server to implement continuous processes of applying quality control in general — small pieces of effort, applied frequently. In addition to running the unit and integration tests, such processes run additional static and dynamic tests, measure and profile performance, extract and format documentation from the source code and facilitate manual QA processes. This continuous application of quality control aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development. This is very similar to the original idea of integrating more frequently to make integration easier, only applied to QA processes.

A Gentle Introduction

Minimum Requirements

Building a Solution

Hello Continuous Integration

The Software

Building on the CI Server

Receiving a Build Failure Notification

Build Scripts

Note:

Building a Solution:

Build means compile and link only the source files that have changed since the last build, while Rebuild means compile and link all source files regardless of whether they changed or not. Build is the normal thing to do and is faster. Sometimes the versions of project target components can get out of sync and rebuild is necessary to make the build successful. In practice, you never need to Clean.
Build or Rebuild Solution builds or rebuilds all projects in the your solution, while Build or Rebuild builds or rebuilds the StartUp project, “hello” in the screen shot above. To set the StartUp project, right click on the desired project name in the Solution Explorer tab and select Set as StartUp project. The project name now appears in bold. Since the homework solutions typically have only one project, Build or Rebuild Solution is effectively the same as Build or Rebuild .

Compiling a Solution:

Compile just compiles the source file currently being edited. Useful to quickly check for errors when the rest of your source files are in an incomplete state that would prevent a successful build of the entire project. Ctrl-F7 is the shortcut key for Compile.

Note:

Microsoft Build Engine, also known as MSBuild, is a build platform for managed code and was part of .NET Framework. Visual Studio depends on MSBuild, but MSBuild does not depend on Visual Studio. Visual Studio Application Lifecycle Management depends on MSBuild to perform team builds via the Team Foundation Server.
MSBuild is a build tool that helps automate the process of creating a software product, including compiling the source code, packaging, testing, deployment and creating documentations. With MSBuild, it is possible to build Visual Studio projects and solutions without the Visual Studio IDE installed. MSBuild is available at no cost. MSBuild was previously bundled with .NET Framework; starting with Visual Studio 2013, however, it is bundled with Visual Studio instead.^[3] MSBuild is a functional replacement for the nmake utility, the latter of which remains in use in projects that originated in older Visual Studio releases.
MSBuild acts on MSBuild project files which have a similar XML syntax to Apache Ant or NAnt. Even though the syntax is based upon well-defined XML schema, the fundamental structure and operation is comparable to the traditional Unix make utility: the user specifies what will be used (typically source code files) and what the result should be (typically an application), but the utility itself decides what to do and the order in which to do it.
MSBuild can build a project against a supported .NET Framework version of choice. This feature is called "multitargeting". Any given build of a project, however, can only target one version of the framework at a time.