When discussing work item type fields definitions, I have intentionally left out the maintenance aspects (to simplify things). Now let us handle some of the complexity related to field definitions.
It is important to understand that all fields defined per work item type are actually defined per Team Foundation server. Defining field in work item may be likened to adding new record to fields’ “global table” (containing name, refname and type columns) with all work item types using that global table. Thus when field is renamed (using witfields rename utility), its name changes for all work item types using that field
Moreover, when you add field to your work item type, and some work item type has already used the same refname, you cannot override either data type or field name. And the following additional constraints apply:
- When field is removed from specific work item type, it does not cease to exist on server (even if it is not used by any work item type); to remove field it needs to be explicitly deleted
- When field is being deleted (using witfields delete), it should be first removed from all work item types
- When the field deleted was used for reporting (reportable attribute set), then you will have to rebuild data warehouse to purge old field and its values
Just imagine that you have created custom work item type and it uses certain field (CR_ID, integer, reportable), then used it in twenty Team projects. If now you need to change field CR_ID type from integer to string, that will involve the following:
- Remove field from WI type definition in all twenty projects
- Delete field from WIT database
- Rebuild data warehouse
- Add field to WI type definition in twenty project
Did I bring my point home – the point being field maintenance (add/delete and to a degree rename) is expensive? The morale of the story is that if you are going to add new field and especially if you desire to delete field, “measure twice, cut once”. Sometimes it may be better to leave unused field (that is not currently used by any WI type) hanging in there rather than going for deletion spree.
5 comments:
Great article! Do you have some "recepies" to solve conflicts in fields validation of changed WI templates on existing data?
Michael,
The only recipe I have for changing templates on existing data - test test test, and do that on the clone of production DB. That way you figure out the conflicts early on.
It was a great post. But how can I add a field like progress to a work item type. Or better, to create a new work item type like "Spec Task" with the same field like the usual "Task" but with one more : "Progress". I tried to add this field but I don't know what kind of ref name should I add...and so on...Could you please help me on this? tintasbarnes@gmail.com
Looks like "witfields delete" does not remove reference to a deleted field in team and personal queries. Neither "witfields view" detects that. One have to manually discover and fix broken queries via removing the reference from the condition and from the column set.
Five years old, and this post is still useful - nice job.
Thank goodness I added fields using a test template (I'm just a project admin, so I can't do tasks such as Data WH rebuilds) - no one will ever see it, so no one will ever use it.
Thanks again, great post.
Post a Comment