When we posted the Orcas Team Build Continuous Integration Spec, you may have noticed that there was no support for scheduling builds.  We implemented build scheduling as a Design Change Request (DCR).  That meant that we had to present a justification for the feature, a spec, and how long it would take to implement and test.  By the time we had the DCR meeting we were nearly done with it.  That made the conversation about the effort involved go a little more smoothly, since we could talk about it largely in the past tense.

Here is an edited version of what Jim Lamb, our PM, put together for the DCR meeting.  Note that the screenshot below is from the actual product.

The ability to schedule builds is something that we’re frequently asked about. There are Connect issues (issue 1, issue 2, issue 3) on build scheduling. We believe that if we don’t ship this feature, our customers will be dumbfounded by our oversight.

The Team Build Team would like to submit a design change for review to allow users to schedule builds to occur on selected days of the week at a specified time. To accommodate this functionality, the following changes would be made to the trigger page of the build definition dialog:

The days of the week are taken from the system based on the locale and laid out within a flow-based layout control. The width of each check box is set to the maximum width of the widest checkbox so that, should they wrap to a second row, they will align with the first row. The drop down list box (editable) includes times from 12:00 AM through 11:30 PM at half-hour intervals. The localized name of the local time zone (taken from the system) is displayed next to the selected time for clarity. When the user selects the scheduled build option, the day selections will default to the first five days of the week. If the user selects the scheduling option but does not select any days of the week, a warning message will be displayed at the bottom of the dialog: “Select the days on which to queue this build definition.”

A scheduled build will not be queued if no changes have been checked in since the previous build, unless the user selects the option to “build even if nothing has changed.” If there are no previous builds a build will be queued at the specified day/time regardless of whether any changes were submitted since the build definition was created (or modified to include scheduling behavior).

1. The determination of what to build is made in SQL.
2. The schedule is represented as a set of days of the week and a local time.
3. On the timer event, identify all build definitions scheduled to be built for today which have not already been built today (using system build time for the build definition) and specify a build time less than or equal to the current time and queue those for build.
4. If the day of the week has changed since the last timer event (stored in the db to handle time changes when the service is down), each build definition’s system build time, which is set only when it’s queued by the system, will be cleared and the schedule re-evaluated.

We are using TFSServerScheduler to invoke a team build web service method (EvaluateSchedules) once every 60 seconds. The evaluation of builds to be queued happens during a single round trip to the DT for both rolling and scheduled build definitions.

There are no new permissions associated with this functionality.

[UPDATE 6/6/07]  Based on feedback, we now support running the scheduled build even when nothing that affects the build has changed in version control.  I’ve updated the screenshot (note the new checkbox at the bottom) and the text above.  As always, thanks for letting us know what you need in these features.