In TFS 2012, there are "To Do", "In Progress", and "Done" columns on the board. I'd like to make two changes. First, add a new column called "Ready for Deployment" between "In Progress" and "Done". Second, have TFS set tasks in this column to "Done" when they are included in a build that finishes successfully. Is this possible?
Sure this is possible, but not how the standard process template is intended to be used. Normally you'd add a "Deploy" task under the PBI/UserStory/Requirement, if deployment of teh item is required. Then, when all other tasks are completed, you do the deployment and if that succeeds you close the parent Requirement work item.
That said, as long as you're not using Visual Studio Online, you can edit the process template of any TFS process to add as many states are you desire. Keep in mind that if you're using Reports, that these might break due to the additional states you'll introduce. This will require you to update the reports (and the standard work item queries and Excel reports) as well.
The Team Foundation Server Power Tools can be used to customize the process template in a graphical editor, which is usually easier than manipulating the WIT-templates manually.
Alternatively, if you're using TFS 2012 update 3 or later, you can add custom columns to the Product Backlog Board and use those instead.
Related
I have many Azure DevOps Extensions. Some recent, but also tasks dating back to 2015 when the extensibility model for build tasks first appeared. Over time much has changed in Azure Pipeline Land...
The biggest changes happened when we moved from UI based pipelines to YAML based pipelines. Some hidden internals of the tasks made their way into the light.
In the past a user would really only see the Task's Friendly Name and Description and Team Foundation Server would keep track of the real identity of the task through its TaskID, a GUID that was never supposed to change.
See a sample below:
"id": "3ca44a28-62de-4c60-8d77-a99065b95a8a",
"name": "VariableSetTask",
"friendlyName": "Set Variable",
"description": "Sets a variable.",
"author": "Jesse Houwing",
With the release of TFS 2017, tasks could be packaged into an extension which caused another identifying element to be created, the extension's publisher, extension id and the contribution ID:
{
"id": "jessehouwing-vsts-variable-tasks",
"name": "Variable Toolbox",
"publisher": "jessehouwing",
"contributions": [
{
"id": "vsts-variable-set",
"properties": {
"name": "vsts-variable-set"
}
}
]
}
These elements were also hidden in the age of UI based pipelines, but also made it to the surface when YAML came around.
steps:
- task: jessehouwing.jessehouwing-vsts-variable-tasks-dev.vsts-variable-set.VariableSetTask#2
As you can see the publisher, extensionid, contributionId and TaskName are now used to reference a Task, whether you insert them through the "View YAML" button:
When using the YAML assistant this will only happen when you have 2 tasks registered in your organization that have the same TaskName property.
Due to the fact that these values are now publicly visible, I've wanted to get rid of some of the bad naming I used in the past:
Get rid of the vsts- in the contribution-id
Remove Task from the TaskName property
Make everything lowercase to match Microsoft's own tasks
I'd love it even more if I could update the ExtensionId, which also references vsts- still.
And remove jessehouwing from the extensionId.
Changing names will of course have impact for existing YAML users, since all tasks are referenced by name, not by Id, but it would make my tasks easier to use for new users and for users moving from UI based pipelines to YAML.
Unfortunately, there are protections in place in the marketplace to prevent people from hijacking other people's extensions. This enforces a number of things with regards to the Task's Id: The Guid.
The Guid must be the same for all versions of a task published in an extension (for backwards compat one can publish a v1, v2, v3 etc in a single extension vsix so users get to chose when they move from A to B.
The Guid must be published in only a single public extension (no restriction applies to private extensions).
The Guid, for some reason, is tied to the ContributionId, whenever you change the ContributionId, you must change the TaskID.
You can't change the TaskID and the TaskName at the same time.
This essentially blocks people from changing the public identity of a Task once published in an extension it seems. When you try the marketplace will fail to validate your extension with an error message:
ERROR: Contribution Microsoft.VisualStudio.Services.TaskId.VARIABLE-TRANSFORM is re-using task ID of some other contribution from earlier version.
To publish the extension, change the task ID.
or
ERROR: All the task versions belonging to Contribution variable-transform should have the same task id.
The tasks at variable-transform/v1 (version 1.4.41) and variable-transform/v2 (version 2.0.41) do not have the same ids.
A possible workaround I see is to publish a new extension with a new Id, new Contribution Id's, new Task Ids and new TaskName, but that would require admin approval and installation of that new extension into any and all of the 6000+ users of the extension. That's an impossible ask.
I could accept that the ExtensionId is going to be impossible to fix and just add new tasks into the existing extensions, with new names, new Id's and all, but that will break the auto-update feature for all of the UI based users (I have no telemetry on how many of these there are), my guess is many, cause many of my tasks provide a UI to make working with script and command lines easier. The ability to seamlessly upgrade from one extension to the next is one of the things I've spent a lot of time on in the past. Adding aliases and sensible default values to input fields causes minimal fuss when upgrading from v1 to v2 for the Variable Tasks for example.
See the example below:
The input type changes from a input field to a dropdown, the YAML representation changes to a lower case for a number of fields and a number of new options appear based on the reflected value in the dropdown. All without the user having to do anything to get access to these new features.
If TFS/Azure DevOps doesn't recognize the Task as a new version of something in the pipeline, users of the UI based pipelines and old Release pipelines (and basically all TFVC users) will need to add a new copy of the task, copy all of the values from A to B and then remove the old task. I do not want to cause them that much pain.
I'm guessing the answer is going to be no, but have I missed any option to allow my users to seamlessly upgrade, yet allow me to keep improving the way new users have to type YAML to access these tasks? I'm not aware of any way to provide an alias identity for the Task itself (previous names, guids), nor for the contribution id... Similarly, I'm not aware of a way to get an extension containing build tasks renamed on the marketplace...
I think that you're already answered your own question:
Keep it this way.
Add new extension(s).
Yes, for a user it's a pain.
Especially when you rely on an admin approval for installing extensions.
You could offer a PowerShell script to migrate all tasks in the pipelines via the REST API of Azure DevOps. But that's still a lot of work and needs a certain technical knowledge (and permissions).
Microsoft tasks are the only one that are really short, but that's probably because it are native tasks and no extensions.
If you look at some extension names in the marketplace you're not the only one with this "issue". Maybe Microsoft will come up with an solution.
On the Azure DevOps TaskBoard for a sprint, it would appear that the only thing I can drag across the board is Tasks. Not bugs. Not Backlog items. Which means if I want to see where a bug is on the board, I have to create a task for it. (Note: My project uses Scrum. Bugs are managed with requirements)
I guess this makes sense. It is a "Task board" after all. But this seems tedious. Most of the time, the bug is the task. I make a bug, make a check in, and mark it done. I would expect to be able to drag the bug itself across the board to mark it done.
And even if I go to the trouble for creating a task for a bug (or a Backlog Item) and then I drag the task across the task board to "Done", the bug's status still stays where it was. It doesn't change to not done. I then have to go to the bug and manually mark it as "Done"
This really limits the usefulness of the Taskboard for our planning.
Am I missing something? Is there way to change this?
You can choose to manage the Bugs with tasks as Daniel commented. And You can use extension Work item form one click actions to assign the Bug to some parent PBI automatically. See below example:
First you need to install Work item form one click actions extension to your Organization.
Then Go to project setting page-->WIT One Click Actions under Extensions-->Bugs-->Create rule group-->New Rule
Triggers: New work item load
Actions: Link to an existing work item(relation type: Parent; Work Item id: Id of PBI)
After above rule is created. The newly created bugs will be automatically added to the parent PBI you specified in above rule.
However, The PBI and Bugs(managed with requirements) can be moved around in Boards. So you can use the filter to view your work items in a specific sprint.
If I create a new project and select the Agile process, my user stories will be grouped in iterations Eg "MyProject/Iteration 1".
However, If I create the project using Basic process and after the project has been created, changes the process to Agile I can group my user stories by Sprint Eg "MyProject/Sprint 1".
The latter is what I want, however as the process was set to Agile when the project was created (not by me), I'm trying to figure out how to change it to use Sprints as default?
Side note:
I cannot create a new project as I lack privileges
I cannot create a new process as I lack privileges
I cannot change to another process because I've already created a bunch or user stories
Although I can create sprints manually, I want it to be default.
Thank you!
From this document, we can know that iteration and sprints represent the same concept in the agile process.
Define Iteration Paths (aka sprints) and configure team iterations
So if you want to visually use Spirits as the default, you can add a new iteration named Spirit in team configuration, or change the name of the existing iteration to the Spirit style. Then set it as Default iteration. As shown in the following figure:
Because your current project is already Aglie process, the initial display must be MyProject/Iteration 1. If you want to display like MyProject/Sprint 1, you have to modify it later.
There are two ways to change the display: changing the process or manually modifying it.According to your Side note, obviously neither is feasible.
If you really want Spirits as default in agile progress project without any manual modification,you could submit a feature request in our Develop Community site. Our PM and product team will kindly review your suggestion.
There is no way to do this without changing the Process of your project.
I have a requirement to update work item status to a ready for test state after the first successful release using TFS release management. It seems like there should be a straightforward built in task to do this but I can't see it. My current thinking is
Use TFS REST API to query the workitems and update them all using powershell
Wrap this up in a powershell task and include in the release definition
This will do the job I reckon. It's yet more powershell in our releases but they are built on a stack of powershell anyway so at least it's well known.
But is there a better (quicker) way to do this? If the answer is a straight 'no' then great - I will accept that answer gladly.
We are on TFS 2015 R4.
Many thanks for any/all help
Sorry, there is no out-of-the-box feature for this by Microsoft.
But we still could use some three-party extensions or tasks to handle this situation.
The WorkItem Updater task can update the following work item fields during a build or release:
Update the state for workitems linked to a build.
Update the assignee for workitems linked to a build.
Add the build as Development Link to the workitems.
The limitation is also very obviously, it could only update work items which be linked to a build. Which seems not be a problem, it's also a good behavior track work items during build pipeline.
Otherwise, you have to use the ways mentioned above to update normal work items after/during a Release.
Can I have guidence for TFS 2010 for the following areas:
What is the correct use of tfs and the properties that are exposed for each backlog item and task for recording of effort so that we report on progress using the burndown charts and can assess velocity.
It is not obvious to us what is the appropriate workflow for raising questions about functionality against tasks / user stories so that the person who needs to answer them can easily find those tasks / stories that have outstanding questions. And for when the question is answered how the person(s) who need to know the answer are alerted that the answer is there. Maybe tfs is not the right place to do this and we should be manually doing this?
Unless you customized something, the report features you are asking about will light up in the reports if you use the field in the Task work item named Remaining Work - update it regularly - daily if possible.
The database most of the default reports use (Tfs_Analysis) gets updated every 2 hours by default. Some of the reports only show a daily roll-up so depending on what you are looking for you might not see changes until the day after.
As for your 2nd question about how to communicate about missing information in user stories, etc.. you should read the Process Guidance for the template that was used to create your Team Project. I'm guessing you are using the MSF Agile 5.0 template, so do a search for that and "Process Guidance." The Process Guidance is basically the instructions for how to use the TFS work items and reports, etc... It can be found online (on MSDN) or by right-clicking on your team project in Team Explorer and choosing Process Guidance from the context menu. I'm answering this from my phone but can include a link to it later if you find this helpful.