I have a request to add a new field to a work item and we are using TFS 2017. My organization has done this before in previous versions of TFS. However, I remember customizing any process template to add new fields causes headaches when upgrading to the next version of TFS.
My question is if this is still a concern? If so, is there a work-around for this issue?
Thanks!
Tim
Basically, you would have the same procedure if you want to upgrade a on-premises TFS with customizations.
So, before you customize, you should understand which customizations support an easy update path and which do not.
Recommended practices:
Identify the best options for customizing WITs that support your
tracking requirements. When you change objects that track work items,
you should identify how these changes will affect existing and future
team projects.
Put processes and all XML definition files under version control. Do
not deploy objects that you define but have not stored in a
repository.
Test your customized objects just as you would test your software.
Minimize the number of custom fields that you introduce. Minimize the
number of fields that you make reportable.
Please refer to the link below for more information:
https://learn.microsoft.com/en-us/vsts/work/customize/on-premises-xml-process-model#before-you-customize
Related
I am about to move a local TFS project to visualstudio.com
When the project was created, it was created with a SCRUM process template. However, only source control functionality was used (except about 20 work items which can be deleted).
I want to add them to visualstudio.com as a project of process template type CMMI.
I am reading confusing (and seemingly conflicting) information on-line about how it is done (and if it is even possible).
Has anyone does this before (or have experience with TFS migrations in general)? Any input appreciated!
Thanks
You can use TFS integration tool to process migrating Source control and work items. As you want to change the process template, you need to put the mapping file during migration. More information, you can refer to this blog: https://mohamedradwan.wordpress.com/2015/05/14/migration-to-vso-visual-studio-online-with-different-tools/
How does your team differentiate TFS work items that are "done" (development/testing complete) vs. "deployed" (live in Production)?
My first option would be to use a Tag to mark this. You can query and filter through them.
Another option would be to customize the work item types with an additional field, but this route is a bit more complex.
Change your Definition of Done to include: Deployed. Doing that you will have code working in production. If is needed more work, is not done.
But I guess you´re asking about how to have a new status. You can modify the workflow template to include this new state. In older versions of TFS you only can do that before to create the project, not in an started project. I don´t know in the latest version.
When you upgrade your tfs server does it automatically update the scrum template your using for existing projects or do you have to do that manually? If manually what is involved?
The team project we are working on was defined in 2012 RTM but our server is now # 2013.3. We haven't used the work items that much at this point (at little bit initially for a pilot project) but we are to push harder for our organization to use scrum so we want to make sure we are on the latest/greatest template before we start.
Your process template is not automatically updated. As long as you haven't made any changes to the original process template, upgrading is quite easy.
You enable new features by running the Configure Features Wizard in your team projects configuration page.
If the automatic update fails, you will get a message describing the errors it encountered. Now you will have to apply those updates manually which is also described on MSDN but is a bit harder.
A not so nice but easy way is to remove all work items and process data from your project and then add the newest items. Martin Hinshelwood has some great guidance on how to do this.
I've been looking into change the process template on a Team Project, but still have a few questions. I'm looking to move from MS Agile v5 to TeamPulse v1. There are no existing work items that we care about, so no need to move those over, however we do want to keep the existing source control history/branches.
With this in mind what is the best method to use? I am currently looking at using witadmin but am also considering TFS Integration Tools (MS or CodePlex versions). I think these are essentially my only options.
Do I need to worry about mapping existing fields to those in the new template if I don't intend to keep the current items?
Any additional advice would also be welcome.
It is not possible to explicitly change the Process Template, though it is possible to import the new work item type definitions using witadmin
I found the following answers helpful in finding a solution:
https://stackoverflow.com/a/2999219/509356
https://stackoverflow.com/a/5664531/509356
If you don't need any existing workitems I recommend to create a new team project with TeamPulse v1 and migrate only the source with the TFS Integration Tool. The problem with the witadmin solution is that you won't be able to delete the old workitem definitions and that could lead to confusions.
We have recently transitioned from Gemini to TFS for application change control. There is one aspect of TFS I can't get my head around - the lack of a built-in concept of the application version that each work item will be addressed in.
In Gemini every feature request, enhancement, bug etc can be tagged with a version number. If the field was left blank, the item was "unscheduled", i.e. on the backlog. Each version could be flagged as either released or not. Reports could be then created listing the issues addressed in each released version, i.e. release notes, and the issues to be addressed in future versions, i.e. a roadmap. I was completely happy with this!
Now in TFS I can't find any built-in concept of version. It seems like there are 2 ways to represent version:
As a parent item in the iteration tree, e.g.
Version 1.0.0
Sprint 1
Sprint 2
etc
Version 1.1.0
Sprint 3
Sprint 4
etc
As a parent item in the work items tree, e.g.
Version 1.0.0
Requirement 1
Requirement 2
etc
Version 1.1.0
Requirement 3
Bug 4
etc
The latter approach looks better because it allows versions to be worked on simultaneously (e.g. a major release will be worked on at the same time as bug-fix release).
So what is the recommended approach to managing work by version?
Finally, with the version property not actually being present in the work item itself, is it possible to make reports on issues addressed in each version?
For now I am going to use iteration path to capture the version number. This doesn't lend itself so well to managing development on different versions concurrently, but we are trying to get away from that practise (i.e. be working on the next release while simultaneously working on multiple bug fixes to past releases) and adopt short release cycles, i.e. a more linear path, so maybe that is a good thing.
Earlier I though Area Path might be a good place to put Version, but its too valuable as a way to split up a huge application into parts to sacrifice for versioning.
1. Tags (TFS 2013+) are the easiest way to append metadata such as build#. (same as mentioned above.)
2. The CMMI Process Template > Requirement and Bug Work Item Types have an "Integrated In" field that links to TFS Builds for direct correlation from requirement to build# [to related code changes] [to related test cases [to related test results]]. Note you must select from retained TFS Build system builds (that have not been deleted). This hard reference drop-down limits this field significantly over time or if you use a different build system. (That and build versioning are entirely different discussions :-).) The Build CMMI template fields have been there since TFS2010.
3. Create a custom field in your User Story and Bug work items. BuildImplementedIn or similarly named field would do. Creating custom fields is not hard in TFS. You will need a Team Project Admin or possibly a TPC Admin to make the customization if you aren't already an admin.
p.s.: Sorry for the late reply. I posted this answer in case others still have the same or similar question.
You could use the area field.
We use that one for product name (we maintain multiple products) and then version goes into the description of the story, but you could use the area field for versions.
Another possibility is to use tags at the top of the Product Backlog Item.
Btw, I agree that TFS is lacking a few important fields (custom fields)