Continuous integration (CI) is the practice, in software engineering, of
merging all developer working copies to a shared mainline several times
a day. It was first named and proposed by Grady Booch in his 1991
method, although Booch did not advocate integrating several times a day.
It was adopted as part of extreme programming (XP), which did advocate
integrating more than once per day, perhaps as many as tens of times per
day. The main aim of CI is to prevent integration problems, referred to
as "integration hell" in early descriptions of XP. 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.
In XP, CI was 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 in the
developer's local environment 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 ran 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 practiced 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.
In the same vein, the practice of continuous delivery further extends CI
by making sure the software checked in on the mainline is always in a
state that can be deployed to users and makes the actual deployment
process very rapid.
The following child pages outline CI process instructions for TeamCity,
Visual Studio Online (VSO) and Team Foundation Server (TFS):
(Video) Continuous
Integration
Continuous Integration with
TeamCity
Continuous Integration with VSO-TFS
Set up a CI build Your team can minimize errors and increase quality by
integrating the code as frequently as possible and then building and
testing the result. You can define a build process to support this
strategy, known as continuous integration (CI). After this is done, you
and your team can determine as quickly as possible that a check-in has
broken the build or caused a test to fail. Define a build process to
support continuous integration
Improve the function and performance of the build process
Take next steps
Dig deeper
Define a Build Process to Support Continuous Integration In Team
Explorer, make sure you are connected to the team project (Keyboard:
Ctrl + 0, C), and then open theBuilds page (Keyboard: Ctrl + 0, B).
Choose the New Build Definition link or select a build, open its context
menu, and choose Edit Build Definition. Tip Tip If a TF225001 error
message appears, configure a build controller.
On the Trigger tab, choose Continuous Integration.
Tip Tip If your developers have to wait too long for their check-ins to
build, you might want to choose Rolling builds instead. This trigger
causes the build system to build multiple check-ins together. See Use
the Rolling builds trigger.
On the Source Settings tab:
TFVC icon TFVC: In the Working folders table, specify the
version-control folders that contain the files that your build process
requires.
Tip Tip To ensure that your build process functions correctly and to
improve performance, include all folders, and only these folders, that
contain files that your build process requires. For more information
about how to specify these folders, see Work with build workspaces.
Git icon Git: In the Monitored branches list, specify the repository and
the branches that contain the files that your build process requires.
You can use wildcards. For example, you could
specifyrefs/heads/feature* to monitor the refs/heads/featureA and
refs/heads/featureB branches.
To improve performance, on the Build Defaults tab, choose This build
does not copy output files to a drop folder.
On the Process tab, in the Build process parameters table under Build,
specify the solutions or code projects that you want to build.
On the Process tab, set the build process parameters to ensure that
check-ins meet the specific standards of code quality for your team
without delaying your developers unnecessarily.
For more information, see Improve build process function and performance
later in this topic.
Specify build process options on the other tabs. For more information,
see Create or edit a build definition.
Improve build process function and performance To minimize the time that
is required to process the build, you should consider following these
guidelines when you specify values for the build process parameters on
the Process tab.
TF Version Control or Git Clean workspace or Clean repository: For
faster performance, set this value to False. This setting might cause
your team to miss some types of defects, such as those introduced during
refactoring.
Build
Configurations: If you leave this parameter empty, the default platform
and configuration is used for each solution and project. To optimize
performance, adhere to the following guidelines:
If a platform-configuration pair builds more quickly than other pairs,
specify it in this parameter.
Specify as few platform-configuration pairs as possible.
Clean build For faster performance, set this parameter to False. This
setting might cause your team to miss some types of defects, such as
those introduced during refactoring.
Build, Advanced
Perform Code Analysis: For faster performance, set this value to Never.
Test, Advanced
Disable tests:
For faster performance, select True.
If your code must pass certain tests, select False, and then define a
set of tests to run in the build. You can improve performance by running
only the tests that you require. To designate those tests, filter them
by either category or priority. For more information, see Run tests in
your build process.
Publish Symbols
Path to publish symbols: For faster performance, leave this value empty.
Advanced
Agent Settings
Name Filter –or– Tags Filter: Use either a build agent name or a tag to
bind this build definition to a build agent that is designed
specifically for running this build. The build agent should run on
hardware that is sufficiently powerful to process this build quickly
enough to meet your team's performance expectations.
Maximum Execution Time: Set this value to a reasonably small number. For
example, 15 minutes might work for your team, but eight hours is
probably too long.
For more information about Default Template build process parameters,
see Use the Default Template for your build process.
Try this next Make sure everyone on your team checks in (TFVC) or pushes
(Git version control) early and often.
Run tests in your build process
Dig deeper Set up build notifications if you want to be notified when a
CI build is completed.
Use a gated check-in build process to validate changes if you want to
block check-ins that would break the build or fail your tests.
Set up a CI build Your team can minimize errors and increase quality by
integrating the code as frequently as possible and then building and
testing the result. You can define a build process to support this
strategy, known as continuous integration (CI). After this is done, you
and your team can determine as quickly as possible that a check-in has
broken the build or caused a test to fail. Define a build process to
support continuous integration
Improve the function and performance of the build process
Take next steps
Dig deeper
Define a Build Process to Support Continuous Integration In Team
Explorer, make sure you are connected to the team project (Keyboard:
Ctrl + 0, C), and then open theBuilds page (Keyboard: Ctrl + 0, B).
Choose the New Build Definition link or select a build, open its context
menu, and choose Edit Build Definition. Tip Tip If a TF225001 error
message appears, configure a build controller.
On the Trigger tab, choose Continuous Integration.
Tip Tip If your developers have to wait too long for their check-ins to
build, you might want to choose Rolling builds instead. This trigger
causes the build system to build multiple check-ins together. See Use
the Rolling builds trigger.
On the Source Settings tab:
TFVC icon TFVC: In the Working folders table, specify the
version-control folders that contain the files that your build process
requires.
Tip Tip To ensure that your build process functions correctly and to
improve performance, include all folders, and only these folders, that
contain files that your build process requires. For more information
about how to specify these folders, see Work with build workspaces.
Git icon Git: In the Monitored branches list, specify the repository and
the branches that contain the files that your build process requires.
You can use wildcards. For example, you could
specifyrefs/heads/feature* to monitor the refs/heads/featureA and
refs/heads/featureB branches.
To improve performance, on the Build Defaults tab, choose This build
does not copy output files to a drop folder.
On the Process tab, in the Build process parameters table under Build,
specify the solutions or code projects that you want to build.
On the Process tab, set the build process parameters to ensure that
check-ins meet the specific standards of code quality for your team
without delaying your developers unnecessarily.
For more information, see Improve build process function and performance
later in this topic.
Specify build process options on the other tabs. For more information,
see Create or edit a build definition.
Improve build process function and performance To minimize the time that
is required to process the build, you should consider following these
guidelines when you specify values for the build process parameters on
the Process tab.
TF Version Control or Git Clean workspace or Clean repository: For
faster performance, set this value to False. This setting might cause
your team to miss some types of defects, such as those introduced during
refactoring.
Build
Configurations: If you leave this parameter empty, the default platform
and configuration is used for each solution and project. To optimize
performance, adhere to the following guidelines:
If a platform-configuration pair builds more quickly than other pairs,
specify it in this parameter.
Specify as few platform-configuration pairs as possible.
Clean build For faster performance, set this parameter to False. This
setting might cause your team to miss some types of defects, such as
those introduced during refactoring.
Build, Advanced
Perform Code Analysis: For faster performance, set this value to Never.
Test, Advanced
Disable tests:
For faster performance, select True.
If your code must pass certain tests, select False, and then define a
set of tests to run in the build. You can improve performance by running
only the tests that you require. To designate those tests, filter them
by either category or priority. For more information, see Run tests in
your build process.
Publish Symbols
Path to publish symbols: For faster performance, leave this value empty.
Advanced
Agent Settings
Name Filter –or– Tags Filter: Use either a build agent name or a tag to
bind this build definition to a build agent that is designed
specifically for running this build. The build agent should run on
hardware that is sufficiently powerful to process this build quickly
enough to meet your team's performance expectations.
Maximum Execution Time: Set this value to a reasonably small number. For
example, 15 minutes might work for your team, but eight hours is
probably too long.
For more information about Default Template build process parameters,
see Use the Default Template for your build process.
Try this next Make sure everyone on your team checks in (TFVC) or pushes
(Git version control) early and often.
Run tests in your build process
Dig deeper Set up build notifications if you want to be notified when a
CI build is completed.
Use a gated check-in build process to validate changes if you want to
block check-ins that would break the build or fail your tests.
See Also:
1