If I create a custom Build Definition Template from the context menu below, how does one actually edit it?
I can see I can delete it, but not edit. Are Overwrite or Delete & Recreate the only means to edit the Template? Seems a little severe... Neither option seems to give me historical tracking...
Or am I missing something obvious?
As I read https://www.visualstudio.com/en-us/articles/news/features-timeline this is a new feature in the initial phase that will be enhanced with 2017 Update 2 and later (honestly I haven't noticed it arrived in Update 1).
It seems like you actually can "edit" them, by creating a new template with the same name and basically overwrite the old one.
So you could:
Create a new build definition, using your existing template.
Make changes
Create a new template from the build definition with the same name as your current template.
All according to MSDN
Related
I need to create new TFS project template using existing template. i just rename and edited TypeDefinitions and tried to upload it. But it said its already exists. how to edit this as a new project template. please help.
Do you mean import Process Template?
If it is, then you need to modify the Process Template name and Version type ID:
I am new to SpecFlow and I've hit a strange issue.
I have an existing SpecFlow feature and step file. I want to add a new step and when I do this it shows the new step as unbound (purple). Then within Visual Studio 2015 I chose the option 'Generate Step Definitions', it selected the existing step file but then overwrote the file and I lost all the existing steps but my new one was added, how do I just append this new step without losing the existing steps?
Thank you
There are a couple of other alternatives to the one you outlined
One is to go to the 'Generate Step Definitions' dialogue on on there you can select the steps you want to generate the definitions for then click the 'Copy methods to clipboard' button rather than 'Generate', and then paste the methods into the existing step file. IMHO this should be the default option.
The other is to run the tests and check the output, where a the definition required will be part of the failing test output. This option is more viable if you are using a continuous test runner like NCrunch.
Sam has the correct flow. You want to generate the definitions the first time around and then after if step page is already created you will want to copy the steps. If you generate on a page that is already created, it will overwrite the existing steps page and you will lose any changes you made.
I worked out how to do it, for those who are new like me you have to choose the option 'Go To Step Definition' and you will see a snippet code which you must then say 'Yes' to copy to clipboard and then paste the code inside your existing step file.
I would like to get and then edit, programmatically, all of the process paramater metadata from a TFS build definition. Does anyone know how to do that? Thank you.
It depends on what you are after, many of the standard build properties can be set using the TFS Team Project Manager application, available on CodePlex.
Updated based on comments below.
You need to use the TFS API. There's a good intro here. If you need to set custom attributes, you can modify the ProcessParameters (and MSDN)
The ProcessParameters only has entries when the parameter is different to the Default. Try editing an existing build definition and changing a setting to a non-default value. The BuildSettings has the path to the Solution to be built and the configuration to use. This is probably where you want to edit the path to match your branch. Also you need to change the Workspace.Mappings property on the new build definition.
Since our existing project in TFS2010 has a wrong process template, I'm trying to create a new project with the correct process template and use TFS Integration Platform to migrate all work items and version history over to the new one.
However, I'm not quite sure how to migrate all the code over with the current branching structure. Here's our current branching structure:
Main --> Dev
Main --> Release
What I want is after I moved everything from the existing project to new, I can still maintain the same branching structure:
New Main --> New Dev
New Main --> New Release
The questions are:
How do I move all the code from the existing project to the new one? Do I branch like this:
Main --> New Main
Dev --> New Dev
How do I create the relationship between New Main and New Dev?
If I use branching like Main --> New Main to bring the code over to the new project, how do I remove the branch relationship between them afterwards (since I'll retire the old project eventually I don't want people to accidentally merge between the old and new project).
Ok, I give a shot:
Solution 1:
SOURCE CONTROL
Create a new Team Project with the "good" process template
Create a "New Main" branch derived from "Main"
Create a "New Dev" branch derived from New Main, so the same for "New Release"
Merge from "Dev" to "New Dev" accepting the source version in case of conflict. Do the same for "New Release". You won't keep the history in the "New Dev/Release" branches, you'll have to look into their base branch when you'll need to.
WORK ITEM
I'd better use Excel to create the Work Items, I'll first set the query that list all the Work Item I want to copy, display the field I care about, then copy the whole thing (with some mapping if needed) into another spreadsheet connected to the new Team Project, then save everything to create the new work items.
You can do that if:
- you have a reasonable amount of Work Item (you're the one to judge, depending on your motivation ;))
- you don't care about the history (revisions) of a work item.
- you're lazy and don't want to use the migration toolkit (or if it fits your needs).
Solution 2:
In place upgrade of the Process Template, you can do that, but it's mainly done manually.
SOURCE CONTROL
Nothing to do, which is the only way to keep everything intact regarding the Source Control (branches relationship, history).
WORK ITEM
If you want to keep some history use the Excel method I gave you earlier, make sure you got all the Work Items on Excel before adding/changing the WITs
Delete the all the Work Items. See here.
Delete the WIT (tfpt destroywitd)
Add the new Work Item Types.
Create the new ones from Excel if you want to.
SQL REPORTS
Delete the existing reports
Add the ones from the new Process Template
My Take
I'll go for Solution 2 if Source Control is the most important. Using Excel or the migration toolkit depends on the count of Work Items and if there's a lots of fields I can map...
If you go for Solution 2: BACK UP YOUR TPC before doing anything crazy! (I assume you're in TFS 2010)
We have been working on a new TFS process template to better match the process we follow. Is there a way to apply this new template to an existing project.
Try the following free tool:
http://witsynchronizer.codeplex.com/
It allows you to synchronize templates between two projects
There is no "template upgrade" feature in TFS.
You can try to simply update your WITs.
But then you also need to update your queries and reports and shared documents and all. Ugly.
The best way to do this, is to create a new project using the new template (best to use a new TPC), and then migrate your work items over to the new project.