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.
Related
I have been responsible for administrate our TFS projects and have started to investigate the current configurations. I found the following link for determining which process our team projects are connected to: How to determine what Process template an existing TFS 2012 project is configured with?
When using the rest API described in the article above, it seems like the projects depend on a process template called "Microsoft Visual Studio Scrum 2013". When reading this article: Scrum process it seems to me that the process is outdated and should be upgraded to use the "Scrum" template.
I have searched the internet for knowledge on how to upgrade the project to use the new Scrum process but had no luck of finding an answer. Does anyone have an idea of how to update the projects to depend on a newer process? Maybe the whole question is wrongly put as I may lack some obvious knowledge about how these things are meant to work. All I want is to ensure our projects are updated to use the latest TFS technology.
We use Visual Studio 2017 and did recently upgrade our TFS server to TFS 2018.
In general, some new features will be introduced when upgrade from old to new version of TFS.
Generally if you haven't made any changes to the original process template, upgrading is quite easy. Just enable new features by running the Configure Features Wizard in your team projects configuration page.
If it can’t upgrade automatically, you need to apply updates manually. See Add updates to team projects manually.
If you customized the process template, then you can follow the steps mentioned in this link to Update a customized process template to access new features.
To update the existing projects, 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 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
I assumed this would be easy, but I'm not finding anything on it...
I have a project in TFS 2010, which needs to be moved to a new TFS 2015 server. Apparently the project cannot simply be moved normally because it's using a different project template which is not compatible and causes errors when trying to migrate (so I'm told - I don't have any more details on this).
I'm looking for a way to bring over the changesets, keeping history, to the new server. I assumed there was some kind of "dump" where you could export the TFS changesets, then import them into the new server into an empty project - but I'm not finding that option.
TFS Integration is deprecated and apparently doesn't work for TFS2015, with no alternative listed.
I'm open to other creative options like temporarily exporting to a different version control system - for example, I've looked at SVNBridge, but I can't even get that working, let alone figure out if it would help here.
Is there a way to migrate all changesets for a given project and keep history, without migrating the entire project?
There is no default way to migrate changesets in TFS, you would need 3rd party tool, like OpsHub (some features are not free), to migrate the most commonly requested data. Check: http://www.opshub.com/products/opshub-visual-studio-migration-utility/
Or you may consider doing a upgrade from TFS 2010 to TFS 2015, which is a full data transfer. To understand factors that affect your upgrade's compexity, check the requirements and review the upgrade process.
Learn if a dry run makes sense for you, and weigh the benefits and the costs to perform a pre-production upgrade.
When you're ready to upgrade, minimize downtime with the TfsPreUpgrade tool - especially for very large TFS collection databases (> 1 TB). Follow these steps for how to upgrade TFS.
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/
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.