One of the best definition for Continuous Integration comes from Martin Fowler
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.
Continuous Integration and your Development Process
Is your development process Agile? Do you use Extreme Programming, scrum or something else? Is your company deeply rooted in waterfall methodologies? Or do you have a hybrid method that falls between waterfall and Agile? It really doesn’t matter which methodology you use, because you probably pretty much follow pretty much the same process when it comes to writing code.
When you start using Continuous Integration, you will follow the same process. But after you check in the source code, you’ll take additional steps as shown in figure 1.
Figure # 1: The Continuous Integration Process
At this point, you may be asking yourself several questions, such as, “Why do tests need to run multiple times?” or “Why can’t I just click Build in Visual Studio?” The answer to this questions is the same: automating the building, testing and running of other processes through Continuous Integration ensures that the code from multiple team members integrates, compiles and functions correctly, and that it can be reproduced the same way every time on different machine than your workstation. Also, consider that you may have an application with many assemblies you’re responsible for. Even if you are a one-person shop, adopting Continuous Integration will improve the quality of your software.
Automating the build and unit tests are steps in the right direction, but a good Continuous Integration process can do more-and eventually you’ll want it to, so you can maximize its usefulness. Thing like code-analysis tools, running tests in addition to unit testing, building an install package, and simulating an install on customer’s PC are all possible through CI process.
Continuous Integration with Team Foundation Service
TFS2012 uses a build controller to manage software building tasks. You can install everything onto a single server or split the build process across multiple servers. Build agents are services that can be installed on the same or separate machines to distribute building tasks. A build agent pool is a set of one or more build agents. Figure 2 shows a possible TFS build layout.
TFS assigns a build to a build controller. The builds are queued on a given controller and then taken out of the queue one by one or according to a priority and sent to a build agent. A build controller checks in its build-agent pool for a suitable agent to perform the build. After the build is done, the build agent stores the build artifacts and performs notifications.
Figure #2: Possible TFS Layouts
Team foundation build configuration
Before you can add a build to the build queue, you must first define it. You can have as many build definitions as you need. Let’s define a CI build for existing Team Project.
You are by no means limited to a CI kind of process in TFS. For example, you can have CI builds, scheduled builds, or others. If you create multiple types of builds, I would advise using some kind of a prefix like CI for Continuous Build, sh for scheduled and so on.
After you give the build a name, you can decide what kind of trigger will be used to start the build. See figure below.
You can use five possible build triggers
On the workspace tab, you define the working folder that the build agent will use and the source control folders it will pull from. Use the default, unless you have a more complicated source control layout.
On the build defaults tab, since we are using TFS on the cloud, the default will the Hosted build Controller.
On the process, you can stick to the default template, click on the Items to Build navigate to the solution file, and choose it. This is the solution that will use for the Continuous Integration build.
The last tab controls the build retention. You define how long build information should be kept for a given build’s output. From now on, your Continuous Integration build definition runs on the Cloud. Every time you check in something, the build will trigger. To watch the build queue, double-click the build definition in Team Explorer to open the Build Explorer, and choose the queued tab.
Done! You've created your first build in the cloud and, because it's a continuous integration build, any time a team member checks in new code, a build is kicked off. And, this can go a long way in helping your team find and fix build-related issues early.
Continuous Integration in .NET