How might we implement the Change Iteration Automation for the Tfs Automation Platform

as we get organised to start development on the tfs automation platform there is the need to do in-depth investigations into the way things are going to work.

“epic 1: as dave or gary i want wiql queries to be automatically updated when i move from iteration to iteration+1 or sprint to sprint+1”

note: this product is still under development and this document is subject to change. there is also the strong possibility that these are just rambling fantasies of a mad programmer with an architect complex.

this story revolves around on of the most common iteration issues. when i progress from working on “[team project]\r1\sprint 1” to working on “[team project]\r1\sprint 2” i have to go through all of the queries that i created in the “current iteration” folder and update each of the queries to reflect the new sprint.

figure: all the “current sprint” queries need changed

although in this example there are only 6 queries i have worked with teams that have many many queries in this list. i have worked with still more teams that keep creating “sprint [x]” folders and duplicating queries, but that tis another storey.

if there are many queries (15+) it may take more than a minute to edit them. that is enough time for a user doing this manually to get distracted and forget where they are in the list. not good… on top of that this job is just plain boring and is what computers were made to do.

enter the tfs automation platform and one of the core automations of the tfs iteration automation project. what we need is a “change iteration” option on the menu of team explorer…

figure: changing the iteration should be obvious and easy

i can now only apologise for my diagrams i am not the best drawer. there will likely be some sort of configuration screen where you can select options for enabling this automation. for example, are you using area’s as sub projects? if you are then a whole new dimension opens up for having multiple nested queries.

you would also need to be able to select, for each of your projects (wither they be team projects or area projects) which folder to use as your “current sprint” folder so the system knows which queries to change.

figure: setting the new values for current iteration

when the user selects the “change” option the application will queue the tfsautomation.iteration.changeiterationjob on the tfs job service for execution. this will provide some level of resilience in case of the server being restarted during the process. it will also provide an easy way to protect ourselves from 2 users trying to achieve the same task at the same time. we can check to see if the job is already running before starting it and prevent another from starting.

this process will be a welcome first addition to the tfs automation platform and it looks like it is going to exercise at least the ui, configuration and tfs job service sections that we plan on building.

i am really looking forward to getting started on this…