STEPS FOR GATED CHECK-IN BUILD
PROCESS TO VALIDATE CHANGES
When a developer checks in changes
that break the build, the result can be a significant hassle for small teams.
The cost to larger teams can be expensive as measured by lost productivity and schedule
delays. You can guard some or your entire code base against this problem by
creating a gated check-in builds definition.
When a gated check-in build is created, changes that the
developer submits are placed in a shelveset and automatically built in your
build system. The build must be successful for the check-in process to be
completed. If some of your users must bypass gated check-in, you can set the Override check-in validation by build permission to Allow for a group of your users.
To perform
this procedure, your Edit Build
Definition permission must be set to Allow.
To define a
gated check-in builds
- In Team Explorer, click the team project in which you want the build process to function.
- On the Build menu, click New Build Definition.
- The New Build Definition window appears with the General tab displayed.
- In the Build definition name box, type a name.
- On the Trigger tab, click Gated Check-in accept check-ins only if the submitted changes merge and build successfully.
- Click the Workspace tab. In the Working folders table, map the version-control folders that this build definition will control to local folders on the build agent.
- Click the Process tab. In the Items to Build parameter, specify the solutions or code projects that you want to build.
- Set the parameters to ensure that check-ins meet the specific standards for code quality of your team without delaying your developers unnecessarily.
- Click the Build Defaults and Retention Policy tabs, and apply appropriate settings in each tab.
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.
Required node
·
Items
to Build, Configurations
to Build: 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.
·
Automated Tests:
·
For fastest
performance, set Disable Tests to True.
·
If your code must pass
certain tests, set Disable Tests to 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.
·
Clean Workspace:
For faster performance, set this value to None (recommended)
or Outputs.
However, your team is more likely to miss some types of defects (such as those
introduced during refactoring) if the workspace is not cleaned.
·
Perform Code Analysis:
For faster performance, set this value to Never.
·
Source and Symbol
Server Settings, Index Sources: For faster performance, set this value
to False.
·
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. For example,
developers on your team might not mind waiting 15 minutes for the build to
finish. But your developers are not likely to accept having to wait eight hours
before they can determine whether their code has successfully checked in.
·
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.
·
Copy
Outputs to Drop Folder: The system takes
this value as False,
even if you set it to True.
·
Create
Work Item on Failure: The system takes
this value as False,
even if you set it to True.
·
Label
Sources: Set this value to False.
How Gated Check-in Builds are run
Each gated check-in build definition can have only one
running build at a time. Therefore, large and active teams are more likely to
develop a large queue of gated check-in builds. The following best practices
can help your team avoid blocking progress:
- Dedicate a build machine that has powerful hardware (for example, a fast processor and a fast hard disk) to the build agent that your gated check-in build definition uses.
- Define the build so that the build agent does only the work that is required to validate the quality of code that is being checked in.
Automatically Run Gated
Check-in Builds
A gated check-in build is run automatically when either of
the following events occurs:
- A build has been defined with the Gated Check-in check box selected on the Trigger tab of the build definition.
- Someone attempts to check in one or more changes that intersect with any of the mapped folders in the Workspace tab of the build definition.
Manually Run Gated Check-in
Builds and Private Builds
Developers who want to feel more confident about the changes
that they are checking in can manually queue a build of a shelveset. When they
take this approach, they can specify one of two options for what the system
does next if the build succeeds:
System checks in the changes (manual gated check-in build): This option can be handy for
developers who want to validate their code before checking in but who work on a
team that does not use the gated check-in trigger.
System does not check in the changes (private build): Developers can use this option when
they want to validate some changes in a shelveset but not check them in.
No comments:
Post a Comment