We are in the process of the installing and configuring TFS 2015. Part of it, I am installing SharePoint 2013 on the same box as TFS. I don't want to create all service applications given by Configuration wizard as it slows down the server. I just want to create bare minimum which are required by TFS.
Anyone knows exact list which service apps used by TFS?
Related
How to migrate a TFVC project from TFS to AZDO ?
Goal:
Is to migrate host projects on (TFS 2017) using TFVC, to switch them to Azure DevOps Service (AZDO) using TFVC there too.
My context:
TFS 2017 server version 2 hosting current source projects.
AZDO 2019 service wanting to host projects targeted on TFS.
Context wish:
Keep the history of source projects (TFS) on AZDO services.
I Just want to migrated the projects (TFS) in TFVC to (AZDO) in TFVC, without doing any TFVC -> GIT conversion.
I would like to avoid updating the TFS 2017 server for 2018 then to
the AZDO server to switch to AZDO services afterwards.
You understand
that is a lot of step to just want to switch a project in TFVC on
TFS2017 to a TFVC on AZDO
The easiest way to migrate is to upgrade your TFS2017 server to Azure Devops Server 2019 and then using the full fidelity import feature to upload your whole database backup to Azure Devops Service.
At the moment migration tools support TFS2018u3 as well as Azure Devops Server 2019 and 2019u1 as well as 2020 can be imported into the service. We do these kinds of imports regularly and it's a very straightforward process to restore your TFS server backup to a temporary SQL server, install the correct version of TFS/Ads and have it perform the upgrade in-place during the installation. Then use the migration tools to import the collection into Azure Devops Server. Depending on the size of your collection this may take between a couple of minutes to a couple of hours. I've done the upgrade on my laptop on certain occasions as well, installing Azure Devops Server and SQL Server Developer edition directly on Windows 10. Even a trial versions will do.
For all the details on the. Import process, see:
https://learn.microsoft.com/en-us/azure/devops/migrate/migration-import
If you want to import your tfvc project from one TFS servers to another TFS server/Azure Devops Server, you can detach the project collection on you current TFS server and bacmup/restore the database on another server. It will automatically be upgraded
If your project collection has multiple projects, you can delete the projects you don't need after attaching and upgrading your collection.
There are a few tools to perform a history replay from one server to another, those tools can't import everything, your changes id's will change and you'll lose the exact date a commit was made (and possibly the user who made the commit if that account no longer exists). Tools like:
https://www.opshub.com/products/opshub-visual-studio-migration-utility/
Depending on how old and how big your collection is, it may take many hours to migrate the data. If data has previously been deleted/destroyed or branched across projects or edited during branch operations, then the replay may fail or may be forced to perform alternative actions, some of these operations are no longer supported. I've used opshub on a couple of projects and some it completely failed to migrate, others migrated with incomplete or incorrect data. This was 4 years ago, maybe these were bugs and they were fixed, but since the import tools have been released we've used those almost exclusively.
PS: using tfs-git to convert (part of) your TFVC repo to git would be an alternative which I'd recommend you look into further. TFVC has been declared feature complete and has received very little love in the past few years. It's not supported by the new Multi-stage YAML pipelines, the integration for VS Code has been deprecated, the cross platform commandline tool for tfvc has been deprecated and therefore support for eclipse and rider and intellij as well. Team Explorer in VS 2019 is now pushed to the background with the release of the new git features which have escaped the Team Explorer window. It's clear that TFVC is fighting for a lost cause and that Git is winning, you'll need to switch over at some point.
We are looking to carry out the following TFS upgrades in our Production environment:
Upgrade TFS 2010 to TFS 2013.5
Upgrade TFS 2013.5 to TFS 2019
To support both migrations, we have a Windows Server 2019 Standard edition to host the Application Tier. The Data Tier is to be installed on a dedicated SQL box.
The Microsoft website however lists Windows Server 2012 (Essentials, Standard, Datacenter) as the latest server operating system edition required for TFS 2013.
My question therefore is, can we still perform this planned upgrade to TFS 2013 on a newer edition of Windows Server, in our case Windows Server 2019 Standard edition?
I agree with Daniel, please follow the documentation exactly.
Since you can upgrade from TFS 2010 --> TFS 2012.3 --> TFS 2019, or from TFS 2010 --> TFS 2013.5 --> TFS 2019, you could consider trying to upgrade from TFS 2010 to TFS 2012.3 or TFS 2013.5 on the same Windows Server 2008 R2 Enterprise server, and then migrate to Windows Server 2019 Standard edition when upgrade to DevOps Server 2019.1.1(TFS 2019.1.1).
"Supported" means "tested and known to work". Later OS versions haven't been tested and may not work, or TFS may not even install in the first place.
I've done dozens of TFS upgrades in my day. My suggestion is to follow the documentation provided by Microsoft exactly. If an OS isn't listed as a supported OS, then don't use that OS.
So after much to-ing and fro-ing and numerous debates and suggestions from various sources on Stackoverflow, in the end this is how I managed to successfully complete my migration upgrade from TFS 2010 to Azure DevOps Server (TFS) 2019.1
There are however 5 very important points I wish to emphasise:
This was a complete migration upgrade (not an In-place upgrade) and so each move to a later TFS version was done using new/replacement hardware.
Both upgrades were done, based on the excellent YouTube tutorial by Mohamed Radwan which can be found here and relies heavily on the TFSBackup and TFSRestore utilities, both of which have shipped with all versions of TFS, I believe since the 2012 edition.
I only migrated the TfsConfiguration database and our Project database.
There was no migration of SharePoint.
There was no migration of Reporting Services.
We had no scheduled backups set up in the TFS 2010 Admin console.
TFS 2010 to TFS 2013 - Some Useful Points to Note
The backup of my TFS 2010 databases were executed from the Tools directory of the TFS 2013 instance (once installed), on the new dedicated hardware for my app tier.
Following a successful database restore using the TFSRestore utility, there are generally three key tasks required which use the TFSConfig tool to ensure data integrity between the two TFS instances aren't compromised or corrupted. These are the PrepareClone, ChangeServerID and RemapDB tasks executed in this same order.
The PrepareClone task failed when executed and after days of trying to troubleshoot the issue, I gave up in the end due mainly to the fact that the PrepareClone command removes information about scheduled backups, SharePoint, and Reporting resources from an Azure DevOps Server deployment and is used in two circumstances:
When you move a deployment to new hardware but want to keep using the old deployment.
When you clone an Azure DevOps Server deployment.
We didn't have any scheduled backups, SharePoint or Reporting Services included within the scope of our migration and were certainly not planning to keep using the old deployment long-term, except for a few days of validation and testing of the migration upgrade. As such, I ignored the error.
I was also counting on the fact that if the ChangeServerID command run successfully, this would ensure that the two instances were now discrete anyway, having been assigned unique GUIDs. Fortunately, the ChangeServerID task succeeded.
I also then executed the RemapDB command but in truth this wasn't even required as the ChangeServerID command had already completed the remapping task.
From this point on, the migration went like a dream and there was absolutely no issues encountered. Another key point to add, the backup of our TFS 2010 instance was done only after I'd ensured there was no user logged onto the system and following the backup, I took the 2010 instance completely offline.
TFS 2013 to Azure DevOps Server (TFS) 2019.1 - Some Useful Points to Note
Again using the TFSBackup and TFSRestore utilities (this time from the Azure DevOps Server 2019.1 Tools directory) and pretty much repeating the steps for the previous migration upgrade, I managed to get us onto our target 2019 instance without single hitch.
Even better, with Azure DevOps 2019, the TFSConfig PrepareClone, ChangeServerID and RemapDB tasks have been incorporated into the app tier configuration wizard, meaning you're not required to manually run them from the commandline. The tool takes care of it for you in its entirety, which is excellent!!
The new Pre-Production Upgrade option enabled me to simulate and somehow perform a dry-run of the final upgrade, another excellent feature incorporated into the Server Configuration Wizard for Azure DevOps Server 2019.1
My Concluding Remarks
Judging by how easy and simple it was to use, its heavy use of automation and clearly being far less likely to result in any disaster, I am rather surprised the TFSBackup and TFSRestore tools aren't recommended as perhaps the current best migration options, subject of course to the type of migration targeted.
I have done TFS upgrades in the past which were based on the older process of quiescing the project collection, detaching and re-attaching the database(s) to the target instance, etc, etc and must admit there's hardly any chance I'd be going back to that in future if I can help it, as the TFSBackup and TFSRestore tools are a much, much better, safer and reliable option in my view.
Hopefully, this feedback will help the next person who may embark on a similar journey to upgrade TFS from the 2010 edition to a later version.
I installed the Team Foundation server 2017 on my PC. But unable to add another member to a team.
Should I install the Team foundation server on server computer?
TFS can be installed both on a Windows server or client operating system. Note: TFS 2017 only supports 64-bit operating systems.
While TFS supports installation on client OSes, we don't recommend
this except for evaluation purposes or personal use. TFS installations
on client OSes don't support integration with SharePoint products or
reporting. The TFS proxy can't be installed on client OSes. If you
need to use any of these features, install TFS on a server OS.
More details please refer the Requirements and compatibility doc.
To add another member to a team, for TFS, the first time you add an account you must enter the full domain name and the alias. Take a look at this tutorial: Add team members.
My system is an on-premises setup for TFS 2015 and I am trying to get Release Management working with my Jenkins continuous integration system. I have recently added the ""Visual Studio Team Services Continuous Deployment" plugin to Jenkins. After finding out that I need to have Basic Authentication enabled on my TFS server to avoid a 401 - Unauthorized: Access is denied due to invalid credentials. error I am getting to the next error: NullPointerException.
I have looked through the code for the vsts-cd-plugin to see that there is an explicit reference to this API call that I don't believe is in TFS 2015 Update 3...
"/_apis/release/releases?api-version=3.0-preview.2"
Has anyone been successful in using the vsts-cd-plugin with Jenkins and an on-premises TFS 2015 setup? Does anyone have a suggestion on how I can fix this problem to create a TFS Release from Jenkins?
The API version 3.0-preview.2 is for Visual Studio Team Services, it is not included in On-premise TFS. In On-premise TFS, you need to use 2.2-preview.1.
api-version = 3.0-preview.1
Using on-premises: An earlier, and slightly different, version of this
Release Management API is available in Team Foundation Server 2015
Update 2. To use, you must specify an API version of 2.2-preview.1.
New release references a release definition to deploy an application
comprising of one/
You can try to download the source code of the plugin and update the API version and then build it on your local machine and install it in Jenkins.
I've installed the prerequisite (Team Explorer 2013) to the best of my knowledge, but when I try to set up a VCS root to connect to our TFS Version Control server, I continue to get this error message:
"No TFS assemblies were found on the system. Please make sure you have
Microsoft Team Explorer installed. Supported versions: 2015 2013 2012
2010 2008 2005"
The Team Explorer I downloaded from Microsoft just seemed to be a plugin for Visual Studio, which doesn't make much sense as a server-side component. Anyway, I configured a connection to our TFS box within Team Explorer/Visual Studio on my TeamCity server.
So I have two questions that seem to be undocumented by JetBrains:
What does it mean to set up and configure Team Explorer? How can I validate that I have set up and configured Team Explorer on my TeamCity server correctly?
How does TeamCity know how to find the Team Explorer assemblies? Is there some sort of configuration I am supposed to do? Where is this documented?
I guess I'm looking for a true step-by-step set of instructions that make no assumptions about my understanding of TFS or Team Explorer, or any assumptions about what I may have already installed on my TeamCity box.
I've read the two articles on the JetBrains site regarding how to set this up, and they don't cover actually installing and configuring the prerequisites or configuring TeamCity to discover the Team Explorer assemblies it needs.
Team Explorer is the client software that you use to access Visual Studio Team Foundation Server functionality from Visual Studio. You can simply launch Team Explorer on your TeamCity server to create a team project and check in a project, to validate whether it is installed correctly.
I couldn't find any documentation that mentioned how does TeamCity find Team Explorer assemblies. But, based on my understanding, there is no configuration needed to detect Team Explorer. Please make sure your TeamCity server is running under Windows.
If the issue that can't find Team Explorer persists, you can install VS Premium instead of Team Explorer.
Setting up Jetbrains TeamCity for CI with Team Foundation Server:
Install Jetbrains TeamCity
If you are planning on using IIS or TFS on the same server, configure Jetbrains TeamCity to run on a port other than 80 or 8080
Once TeamCity is up and running, you can begin configuring your TeamCity installation for CI Builds.
Log into TeamCity with your user name and password
Create a new TeamCity Project
Create a new build configuration
You will now see a series of build configuration settings that you will have to complete presented in a Wizard-style navigation view.
Enter General Settings
Enter VCS Settings
After entering VCS Settings, Create and attach new VCS Root
Enter the relevant information for your TFS instance
Create a Build Step using Visual Studio as your build runner. You can create as many build steps as you need and specify the order of the steps (similar to a TFS Build Workflow).
For setting up Continuous Integration builds, you will need to specify a Build Trigger. CI Builds will generally use a VCS Trigger that is triggered on each source control check-in.
If you need to pass any parameters to your build, you can configure these in your Build Parameters.
That is all! You can then either run your Builds manually by clicking on the Run button in TeamCity or simply verify that your builds are triggered by the next check-in into TFS.