Cascading Build Definition: Decreasing developer wait time

One of the bigger issues with continuous integration (CI) and gated check-ins (GCI) is that developers check in the code and then have to wait for the build to finish.  CI could potentially be building for multiple data centers and environments, resulting in many builds that need to be completed, resulting in a long wait times for each check-in no matter the size of the check-in.  How do we solve this?  Enter cascading build definitions.

Cascading Build Definitions

Cascading build definitions (CBD) is a term I use to refer to build definitions that trigger each other.  In this scenario, your GCI BD runs when code is checked in and then triggers your CI BD once a successful build has been determined.

The GCI BD should run only one build to determine that the code checked in does in fact build and should target the Release configuration unless there is a reason to target a different configuration.

The CI BD will be triggered only if the GCI is successful.  The CI BD will build for how ever many times you need, which is usually equal to or greater than the number of environments you have in your CD process.

Once the GCI BD is done, the developer is now notified, they can reconcile their build definition and move on while the CI BD triggers behind the scenes and starts its process.  This can be thought of as a multi-threaded approach.

Setting up your Gated Check-In build definition

This build definition is very simple as all you need to do is the following:

• Get sources
• Restore nugets (skip this if you aren’t using nugets)
• Build

The Build step should only be building for one platform/configuration combination, such as Any CPU|Release.  In Triggers, Continuous Integration should be turned off and Gated Check-In should be turned on.  Under Gated Check-In, “Run continuous integration for committed changes” should be turned on.

Setting up your Continuous Integration build definition

You CI build definition will run whatever you need and this is where you’d put your multipliers (multiple platforms or configurations).  This should run 1 to many times.  In Triggers, Continuous Integration is enabled, but Gated Check-In is off.  The enabling of CI will automatically set the build definition to wait for the repo to be updated, then it will be triggered.  This build definition will not be triggered when a developer checks in code, nor will it even be an option when the developers check in code.