We are using TFS 2017 update 2 on-premises.
We want to update our test environment with the build definitions from production. With an extension we could copy the build definitions https://marketplace.visualstudio.com/items?itemName=onlyutkarsh.ExportImportBuildDefinition , but this does not export the task-group of the build definition.
Are there ways to export the task group and import it in another project or in my case in a different TFS server?
The functionality to export Task Groups is certainly present in VSTS. Although the documentation says that is is available in TFS 2017,
https://learn.microsoft.com/en-us/vsts/build-release/concepts/library/task-groups
We haven't seen the References tab being added as of writing this answer. We are using TFS 2017 Update 2. I haven't seen it being added for TFS Update 3 either
Task groups are stored at project level, and are not accessible outside the project scope. So Export/Import build definition extension can export/import task group in the same team project only.
Export/Import task group function as #Hamid mentioned is available in TFS 2018 and VSTS. You could consider upgrade to TFS 2018 to enjoy this new function.
Related
I know i can link my variable group stored in Library into a Release Definition, but my build definition doesn't have an option to link the variable group. I see it is available in TFS 2018. We are not upgrading our Prod instance from TFS 2017 anytime sooner. Is there any out of box method/way that i can link and read the library group?
Is there any out of box method/way that i can link and read the library group?
Sorry for any inconvenience.
I am afraid there is no such out-of-the-box method to link variable group in TFS 2017 Build definition.
There were many user voices about it before, and this request is resolved at Team Foundation Server 2018, MS team has no plans to apply it to TFS2017:
Variable group support
Variable groups have been available to use in release definitions, and now they are ready to be used in build
definitions, too. Learn more about creating a variable group. This has
been developed and prioritized based on related suggestions for
project-level build/release variables and variable groups in build
definitions.
And, AFAIK, there is currently no better workaround to solve this issue for TFS 2017.
So, we have to repeatedly define variables for each build pipeline before updating our TFS to 2018.
Hope this helps.
I was able to get TFS 2017 variable groups in JSON format. I'm now loading the JSON and instantiate the library groups.
http://tfsinstance/collectionname/teamproject/_apis/distributedtask/variablegroups/
Idea is to encapsulate this as a custom task and fetch required variable groups in the build definitions.
Variable group,in tfs 2017, are available only in release :(
how to migrate a single project alone (where project collection contains 30+ projects) from TFS to VSTS with all history, build-definitions, changesets
Microsoft has documentation on this exact scenario which can be found here: Migrate to Visual Studio Team Services : Move from Team Foundation Server (TFS) to Visual Studio Team Services (VSTS) and bring your data along.
This link also contains the download link for the migration tooling which you will want to use
Currently the following versions of TFS are supported for import:
TFS 2017 Update 3
TFS 2018
TFS 2018 Update 1
As described in About VSTS and TFS, Scope and scale data, the
long term direction for VSTS is to support grouping of accounts within
organizations. This would lead to:
VSTS accounts that serve as the equivalent of TFS project collections and VSTS organizations that serve as the equivalent of
TFS deployments.
This is why the TFS Database Import Service only supports importing single TFS collections as single VSTS accounts.
If you need to migrate individual team projects you will need to use
one of the other options—manual copy or public API based
migrations.
Source Link
It's very clear why you could not use TFS Database Import Service to migrate at team project-level directly.
You can also have a try for VSTS Sync Migration Tools,it allows you to bulk edit and migrate data between Team Projects on both Microsoft Team Foundation Server (TFS) and Visual Studio Team Services (VSTS). Note this without history. How to please refer: TFS 2017 Migration To VSTS with VSTS Sync Migrator
If you insist on keeping all history, the only way is using TFS Database Import Service, you may take the workaround as Daniel suggested.
We just upgraded from TFS 2013 to TFS 2017 and I was excited to go in and create a new build definition, but I can't seem to do it at the collection level. I can only create a new build definition once I've selected a project and then when defining the Get Sources page I can't seem to access other projects within the collection. The highest level it will allow me to get is the current project. In the Repository drop-down the only option is the current project. How can I create a new build definition across projects in TFS 2017?
The TFS build is project level for now, it's not able to create a build definition at collection level and across projects. For 2015 you could, instead of using the trigger path '$/{team project}', also insert just '$/', which would result in that the continuous integration build triggers on all check-ins in that team project collection. It's more like a backdoor.
However, In TFS 2017, it 's no longer possible to freely edit this field, and that you can only add a trigger for the team project that the build definition resides in.
There had been a uservoice and got started:
VSO build vnext: share build templates between projects
https://visualstudio.uservoice.com/forums/330519-visual-studio-team-services/suggestions/8468566-vso-build-vnext-share-build-templates-between-pro
As a workaround you could export your existing build definition in the project to other project. However, this just avoid you manually duplicating the definition in another team project. It's not able to get source from another project which different with the build definition belongs to.
There is an Export/Import Build Definition extension in Visual Studio Marketplace you can use now. Also available from within the TFS2017 update1 Build Definitions web UI:
.
HELP!!
I'm learning on the fly here with no training whatsoever! I'm a system administrator who is responsible for supporting the developers. They use Visual Studio, TFS, Plastic SCM and TeamCity amongst other tools.
My task was to get TFS 2015 and SQL Server 2014 installed on a new VM. This I have done but my biggest task now is setting up TFS which seems complicated.
For your information, The developers use TFS 2012 as a Kanban board.
Can anyone point me in the right direction to documentation that simply explains how to copy a project from one collection to another? I'm reluctant to move the project to the new version of TFS without testing the current project.
Thanks in advance.
You cannot copy a single project, there is the TFS integration platform, but it sucks and doesn't officially support TFS 2015
I would say your best bet is to follow the following steps.
In TFS 2012, detach the collection using the TFS Admin Console.
Backup the collection database in SQL server
Copy the backup to the new SQL server
Restore the Database
In the TFS Admin Console in TFS 2015, attach the collection
Wait for TFS to update the Database Schema.
You should now have the full team project collection available in the new server.
We are planning to upgrade from Tfs 2012 to Tfs 2013. Can anyone help me understand the difference in process templates between them? We use all three process templates for different projects.
The changes are very minor, except for:
The introduction of Portfolio backlogs.
Test Plans and test Suites are now Work Item Types (TFS 2013 update 3).
The AgileConfig and CommonProcessConfig files have been merged to a single file inside the template
The minor changes:
Git support for the Source Control options
Stackrank type fields are now hidden by default (because Agile task boards are now features of the Standard CAL).
Tag field support through the API.
The easiest way to visualize all differences is by comparing them through the TFS Team Project Manager which can be downloaded here.
TFS 2013 did not work well with our existing workspaces defined on remote network drives. TFS 2012 did work with this configuration.
After working several hours with our System Administrators, we gave up on trying to get the trying to get the existing network drive workspaces to work with the TFS 2013. Converting the workspaces to local drive locations enabled us to work with TFS 2013.