You can schedule builds in Orcas

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.

Comments (19)

  1. vikasgoyal77 says:

    Thanks for the feature Buck.

    vikas goyal

  2. MSDN Archive says:

    random thought fodder (mainly DST) for the next blog post:

    – it says "local" time – local to which? client? build machine? database machine?

    – the screen shot says "Eastern Standard GMT-5" – does it really mean "Eastern with DST" (GMT-5 sometimes, GMT-4 other times) or is DST not a factor?

    – If I schedule for 2:30am, do I get 2 builds on one day of the year and no builds on that other day (DST switches)?

    – what if I want to schedule it for a UTC time (say, 6am UTC)?

    – what if the timezone changes on the relevant machine(s) (build machine or database)?  Since it’s not going off of UTC, this seems relevant.

  3. Hoy en cosas interesantes: Hackers atacan Internet, Administrando los buzones en Exchange 2007, Creando

  4. Brian Harry on Update on TFS and the upcoming Daylight Savings Time changes in the US. Nikhiln on…

  5. Jarle Nygård says:

    "A scheduled build will not be queued if no changes have been checked in since the previous build"

    Does this mean that if we have a "nightly build" that does a whole lot more than just compile a bunch of code it will not run unless somebody has checked-in some code?

    That would make this useless to 3 of our builds…

    We need to deploy new databases on a regular schedule and we do so by creating a new database each day, named after the day. So we have a MONDAY and a TUESDAY etc. database. These are updated with scripts and the code is compiled and deployed to test servers.

    This needs to happen very single day (Mon-Fri).

    We currently use Windows Scheduled Tasks to make this happen.

  6. Buck Hodges says:

    James, those are good questions.  What we do is display the time to the user in the user’s local (client) timezone.  The server stores it as an offset from midnight in local time on the data tier, so the data tier’s clock is the one used for all scheduling decisions.  We use local time so that the builds will still occur at the proper time when DST changes.  If the time were stored in UTC in the data tier, the builds would be off by an hour when DST changes.

    Of course, if your data tier is in a locale that observes daylight savings time differently than the client, there will be some discrepancies.  In fact, the data tier, client, and build machine could all be in different locales each with different DST rules.  We chose not to address that.

    The scheduled build is executed once per day.  Once it has executed, changing the clock within the same day or changing the scheduled build time will not trigger another build for that day.


  7. Buck Hodges says:

    Jarle, yes if no checkins have occurred, then the build will not occur.

    We had at one point considered having an option to "force" a build even there had been no checkin.  We didn’t have data on the usefulness of that.  We’ll re-examine that decision as a result of your feedback.



  8. Jarle Nygård says:

    Excellent! :)

    Wow, how good does it feel to be able to give direct feedback and actually have somebody is is someone give direct feedback in a matter of hours? If just all companies and dev team were like this… :)

    Thanx a bunch for listening.



  9. Buck Hodges says:

    The interview, which contains a demo, has finally been posted (you may remember it being mentioned in

  10. Buck Hodges says:

    As Jeff Beehler points out , we shipped TFS one year ago today. In the intervening time, we reorganized

  11. Roy Osherove says:

    You should consider allowing both "Build on check in" and "nightly". The two are not mutually exclusive..

  12. Buck Hodges says:

    Roy, what would you expect to be different about the nightly build?  We debated this when we put in the feature, but we decided that since there wasn’t going to be a way to provide a different set of parameters to the build, there didn’t seem to be much of a point.

    I’m interested to know what you have in mind.


  13. As one of the developers on Process MeNtOR TeamGuide, i thought for my first blog post I awould describe…

  14. Morten says:

    Hello Buck,

    I have to second Jarle’s motion to have a "Force Build" option.

    In our scenario, we have a CI build that is fired on every checkin. This builds the entire solution and runs all unit tests. What we want to do on the nightly build is to build the entire solution, run all unit tests, run code analysis and fire up FitNesse to run a bunch of acceptance tests. So the two builds are totally independent of each other, and we need the nightly build to be run regardless of whether or not anything has been checked in since the last build. (With our CI approach, that would probably mean that the nightly build would never be run).


  15. Buck Hodges says:


    In your case, your scenario will work as you want.  Whether or not the CI build definition has been built today has no effect on whether the nightly build definition will be built.  The only thing that matters for the nightly build definition is whether there have been any checkins.  The fact that the CI build has occurred actually has no effect on whether the nightly build runs.  So, they are independent like you need them to be.

    I hope you’ll be able to try out beta 1!


  16. Buck Hodges says:


    I apologize for not following up earlier.  Morten’s comment reminded me that I should write more about how it turned out.

    Before I tell you the background, I want to put forth a workaround.  You could have the nightly build always modified a text file that’s mapped for the build definition at the end of the build (if it’s not mapped in the build definition’s workspace, it won’t trigger the build).  That would have the effect of guaranteeing that there is always a checkin that will force the next night’s build to run, regardless of whether there are any other checkins.  You could do this with a couple of Exec task calls to tf.exe.

    When your question came up, I went to the team at that time, and we discussed whether to provide a checkbox that would force a build.  For Orcas, the decision was made not to change it.  Much of the reasoning has to do with minimizing changes to Orcas, as the development was done and this would be viewed as a new feature (build scheduling already was completed as a post-develompment DCR, and we encountered a lot of resistance to changing it further).  If there’s enough feedback from beta 1 on it, we could revisit the decision.  But in order to get approved, it would need to be a lot of feedback from customers wanting this.


  17. Buck Hodges says:

    Back in February, I wrote a post on the build scheduling feature that we’ve added for Orcas. In that

  18. Visual Studio 2008 Beta 2, including Team Foundation Server 2008, is now available for download . As

Skip to main content