We’ve just finished sprint 31 and today we deployed it to the service.  In all, it a modest set of things but some nice improvements.  We’re now starting to get to the point that new things showing up on the service are ahead of what we have in the on premises product.  Some of this will show up in the RTM release of the on premises product and some will show up in incremental updates.  We’re moving to a model of updating the on premises product more frequently – partly to avoid too much divergence between the service and the on premises capabilities.  However, as a general rule, if you want to know what’s coming in the on premises product, you watch the service and see what’s there.

Here’s a screen shot for the first few items on the list below…

image

Improved setting of iteration dates – We continue to work on the experience of setting dates for iteration.  In the Beta it was a cumbersome process and we made some improvements last sprint and more improvements this sprint.  The two main things we did this sprint were:

  • Set iteration dates directly from Task Board and Sprint Backlog pages – Now the links to set the dates are directly in your workflow rather than have to go down a “configuration” path.
  • Smart defaulting when setting iteration dates – Instead of always defaulting the date picker control to “today” (then then you have to scroll through months to set dates for future sprints), we default it to start the day after the previous sprint – clever, eh? Smile  And the length will default to the length of the previous sprint.

Personalize columns for the Product Backlog and Sprint Backlog – This has been a common request.  People want to be able to control what columns are displayed in the backlog lists.  Now you can!

image

Compare the backlog below to the one in the screenshot at the top – I’ve removed the Effort column, reordered State, added Activity, and resized Assigned To.

image

Expand all/Collapse all for the Product Backlog and Sprint Backlog pages – Last sprint, we added expand all/collapse all in work item query results. This sprint we added it to the backlog pages too.

State Transition Diagram on history control – This was a feature we had in Web Access in 2010, a pictorial representation of the state transitions of a work item.  We put so much work into redoing the web UI in TFS 11, we just didn’t get a chance to pull this feature in yet.  We finally got around to it and now you have it.

image

Next/Previous Buttons in Query Results triage view – We added some nice navigation controls for easily moving back and forth through work item query results.  That includes keyboard accelerators.

image

Drag/Drop of Queries in Query Explorer – We added drag & drop to move queries between folders and public/private sections.  Makes it much quicker and easier to reorganize your queries.

Option to create a team area – We got feedback that not everyone wants to create a new area path for every new team.  We added a checkbox to the create team dialog to control it.

Improved Java build support – Previously, one of the impediments to doing Java builds on the build service was that the UpgradeTemplate.xaml (which Java builds use by default) didn’t support dropping binaries into version control (the place you need to put them for the hosted build service).  In this sprint, we added VC drop location support to the UpgradeTemplate build workflow, making this easier.

Shorten build agent working directory – Ahh, our friend the 259 character path limit on Windows.  We were using longer paths (about 32 characters) on the build agents, reserving more of the 259 characters for “infrastructure”.  We’ve now shortened that paths to 9 characters, giving you more access to the path length.

In addition to the fairly visible changes above, we continue to work on the plumbing behind.  Some changes we’ve made this sprint include:

Online account updates – With us updating the service every 3 weeks (and more often than that if you consider hot fixes), it’s really important that the upgrade process is smooth.  Historically, the process has been take down the server, do the upgrade, bring the server back up – Not a good plan for a 24x7 large scale service.  Several months ago, we introduced the ability to keep the service up during upgrades and only to take accounts offline one at a time while we update them.  So no customer was down longer than it took to upgrade their own data.  This sprint we are introducing the ability to even do online upgrades of individual accounts so no one suffers any downtime during an update.  In fact the update today is the first one we’ve executed this way!  Some future updates will undoubtedly be disruptive enough to require some downtime but, from this point forward, I expect most updates will have none.

Improved project creation time – Right now creating a new project on the TFS service averages about 100 seconds (just over 1.5 minutes).  That’s WAY longer than we want it to be but it’s a fairly rare operation for any one person so it’s been lower on our list of things to worry about.  We’re finally getting around to looking at why it’s taking so long.  We made some changes to significantly reduce SQL round trips that we believe (at least our internal testing shows) should reduce the time by about 25% (so about 75 seconds instead of 100 seconds).  Obviously these are averages so any given person might see varying results.  We’ve got more avenues to pursue here and we’re hopeful that the time will continue to come down in the next few sprints.

As usual, it will take several hours before all of the changes show up in all accounts.  We generally update accounts in “most recently used” order – recently accessed ones are done first, crusty ones are done last.  So, if you use your account actively, you should see the updates quickly.

We’ve also been working on some larger changes that we’ll be unveiling soon.  I can’t tell you what they are yet but I’m excited to talk about them soon.

Brian