TFS 2010 Is it easy to change from one process template to another if project only was used as a code repository

4
votes

We started using TFS 2010 earlier this year as a code repository for a new project. To date we have not added work items to the project but plan to do so very soon (currently using TestTrackPro). When the project was created, Agile was selected.

The client now wants the CMMI process template to be used instead. While it is understood that we will need to create a new project and select the CMMI process template, the main directive is to NOT lose code history. Is it as simple as creating a branch from the existing project and binding to the new project? What are the "gotcha's" to look out for, etc.

We have build defs that will not migrate over; no problem as there are not many and not hard to reproduce. We are in a closed network, so bringing over open-source applications is not so simple. And it seems like TFS Integration Platform and witadmin might be overkill. We don't have any TFS experts at our disposal so any thoughts/suggestions/approaches would be appreciated.

3
tfstfs-process-template
possible duplicate of Steps for changing process template for an existing project in TFS 2010 – Betty
What I am finding to be a problem is the inability to "clone" the code repository. I find creating a branch still means I have to keep the original code repository around. It should be simple to create a clone to the new project. Again, I have no sharepoint site or work items to worry about at this point. I need to clone or move the code (with its changesets) from an AgileProject A to CMMI Project B. Any suggestions? I am using TFS 2010. – Glen Luna
You can't clone with history. But you can replace the templates using witadmin like I mentioned below. – Betty

3 Answers

1
votes

It's possible, but it requires heavy use of command line tools like witadmin

There's another thread which goes into this scenario quite deeply but there's a few steps which can be done easier.

Using the tfs administrators toolkit you can certainly simplify the updating of reports, if you happen to have another project with the correct work item templates you can also use it for that instead of witadmin.

(Below is copied from mentioned thread)

Work Items

Either use the tfs admin toolkit mentioned above or witadmin

  • Delete existing work item definitions using "witadmin deletewitd"
  • Import each work item definition from the new process template using "witadmin importwitd"
  • Import work item categories using "witadmin importcategories"

Update Reports

Either use the tfs admin toolkit mentioned above or tfpt

tfpt addprojectreports Add or overwrite reports for an existing team project

SharePoint

tfpt addprojectportal Add or move portal for an existing team project

0
votes

The branch and re-bind approach you suggested sounds like it would work fine in your case.

0
votes

Based on my own experience ( government contracts ) freeze the original project and code base and then create the new committee project and migrate the code tree, that way the history is not lost and if any of the work item templates were modified, this mitigates the risk of merging the two process templates incorrectly