Our TFS 2017 is hosted on a virtual machine (Windows Server 2012). We are planning to upgrade the TFS to 2018. I am planning to create a clone from the VM and running the clone as a second instance with own IP, server name, etc.
I am sure that this will create a nice clone, but I am not sure if this solution is a good way to create a clone of the TFS for upgrade testing. I believe that app- and data-tier still point to the source installation.
Has anyone tried that already and can give me a hand?
You should not clone the VM. Instead clone the TFS instance. There is a procedure to follow when you clone an instance of TFS 2017.
You should make backups of TFS DBs and restore them in a different machine or VM
You should restore and prepare the DBs by changing server IDs and mapping DBs (This step is utmost important to prevent corrupting your current production TFS instance). With TFS 2018 the clone creation is made easy as the configuration wizard will take care of change server IDs and mapping DB Steps.
Configure the cloned instance of TFS.
Do not try to make a copy of the VM and get it up and running which will corrupt both instances of TFS.
Related
We are trying to migrate code from TFS2018 to Azure DevOps. I am new to code migration from TFS to VSTS. I would like to know is there any tool for code migration?
I saw TFS-GIT utility. I am really not sure how much efficient this tool.
GIT-TFS list remote repostiory
You may do it through OpsHub tool: OpsHub Visual Studio Online Migration Utility
My recommendation would be to either upgrade your on-premise server to Azure DevOps Server 2019 or the latest Team Foundation Server 2018 update pack that's supported by the migration tool.
You can perform this upgrade on a clone instance of your existing server, so it won't break or change your existing machine or database in case anything goes wrong.
We regularly perform these types of migrations and we generally use a temporary Azure Virtual Machine. We install SQL Server on it, we restore the backup of the on-premise server, we install the desired TFS application tier version on it. If the Azure machine is joined to your domain, then that's all you need to start the import into Azure DevOps. If the machine isn't domain joined, be sure to turn off the AD Sync job as part of the migration. My colleague Jasper has a couple of scripts to fix that for you.
Alternate options. In my opinion there aren't any. At least not good ones. There is a whole set of tools that an migrate parts of TFS to Azure DevOps, tools like OpsHub, git-tfs, git-tf, Migration Tools for Azure DevOps. None offer a complete migration, some do work items, some sources, some builds, but none of these offer a complete migration.
All of these also have the issue that they reset metadata such as Commit/Approval dates, work item IDs. Which will impact retention jobs, history and other things you may care about.
We have a TFS 2013 instance that requires upgrading. I plan to use Azure DevOps 2019 on prem. I'd like to have the two environments running at the same time so I can verify. What I'd like to do is:
Do full install of Azure DevOps server, creating new DBs on a new SQL server. I do NOT want to upgrade our existing TFS at this point.
Copy the data from the original TFS SQL instance to the new SQL instance, performing an upgrade along the way.
Test and verify all data successfully migrated to 2019
Schedule a blackout window and repeat the import process once again
Can anybody advise if this is do-able or refer me to a guide?
Tks
Easier than I thought. Just needed to run the pre-production upgrade wizard.
We have created a VM clone of our TFS server (but haven't turned on networking yet for the clone).
We have created a test SQL server that we plan on using for the test upgrade.
I'm not sure what we should do first (after populating the tfs databases on the test SQL server).
Since our test TFS server is a VM clone, TFS is installed and configured already. The Cloned TFS server is pointing to our production SQL server. Are the following steps correct:
Turn on networking for the Cloned TFS server
Remote into the Cloned TFS server
Run command TFSServiceControl quiesce
Run the command TFSConfig PrepareClone
Run the command TFSConfig ChangeServer ID
Run the command TFSConfig RemapDBS
Update the TFS URLS in the admin console
Edit Reporting to point to the new test Reporting instance
Update all service accounts
Are the steps correct? I am not sure which order to carry out the steps out after the TFS databases have been put on the test SQL server. Any help would be greatly appreciated.
I would suggest doing the following:
Unconfigure your test server. I assume you don't want to upgrade your production server yet, you just want to test the upgrade, correct? If that's the case run 'TfsConfig.exe setup /Uninstall:All' to unconfigure the new server.
(if you haven't done it already) Backup all TFS databases from production server. You'll need all DBs with the names starting with 'Tfs_' including Tfs_Configuration, Tfs_Warehouse and all collection databases.
Restore TFS backups from production on VM or some other test SQL server (using SQL server management studio)
Run tfsconfig changeserverid command (on the new server) to change the TFS server id. It's required because you want to have both TFS instances live for some time. If you don't do it, VS clients will think that it's the same server (even though the name is different) and this can cause some issues.
Run tfsconfig remapdbs command (on the new server) which will fix the old Tfs_Configuration database. This is only required because you are moving TFS to a different machine (with a different name)
Now you can start TFS management console and perform the actual upgrade which is pretty straightforward. Upgrade wizard will ask you for the new service account names and new test reporting instance location.
I plan on replacing my existing app tier (TFS 2010) when upgrading to TFS 2013. I'll quiesce the services and rename the old machine from MYTFS to MYTFS_OLD. The new app tier will have a fresh, un-configured installation of TFS 2013 and will be renamed from MYTFS_NEW to MYTFS.
My question is, will it be necessary to run the ChangeServerID or RemapDB commands if the new app tier is named the same as the old one?
If I understand your scenario correctly you will end up with:
A new server that's completely clean
The 'old' database server that contains all the TFS databases.
If that's the case, you should install TFS and select 'Upgrade'. You then point your TFS Application Tier to your database server and let TFS upgrade your databases.
You cannot have both version running on the same set of databases.
Study the ALM Ranger's Upgrade guide before doing anything.
I don't think you need to run remapdbs or changeserverid commands:
you typically need remapdbs when the server name changes which is not the case
you should use changeserverid if you plan to clone a TFS server meaning that you have restored TFS databases to a different machine and set up another TFS instance on that machine without killing the original server. Again it's not the case from what you have described here.
We have a TFS 2005 (I think) were we host some code in one domain. Now we would like the customer do host the code by itself and they have bought a new version of TFS 2010. How do I migrate the code from the old server to the new one. We don't care about history at this point since we will have the old system running for at least one year if something critical happen.
What I have done so far is the following:
Create a master branch in the new version and copied the old version to the new version with no problem.
Created a development branch from the master branch.
Now I would like to migrate the development code from the old tfs to the new tfs and this seems complicated.
I first thought it would be as simple as checking out the whole development branch in the new TFS, delete all the files and just paste in the files from the old development branch. But that is not the case.
Maybe there are a simple tool I could use instead?
I know you said that you don't care about history but would you take it if you could get it for free? The best thing to do here is an upgrade, or an import of a Team Project Collection. If you take backups of all of your 2005 databases and restore them on the TFS 2010 data tier you can then run "tfsconfig.exe import". This is the most supported way to get your data from one server to the other.
Follow these steps in the new server:
Create the Master Branch, check-in.
Copy the sources from the old server in the local workspace of the new server at the Master Branch location
Check-in to commit the sources to the new server.
Create the Dev branch from the Master Branch using the latest changeset of the Master branch. This will replicate the whole structure of the Master branch to the Dev one.
Exit Visual Studio
Using the Windows Explorer, delete all the content of the Dev branch in the local workspace of your new server.
Copy the sources from the old server of the Dev branch in the local workspace of the new server at the Dev branch location.
Use the TFPT.EXE ONLINE command of the Team Foundation Power Tools to simulate an offline/online switch that will create the pending changes of the new content of your Dev branch (the files you copied from the old server). Be careful you have everything the way you want it to be in TFS. The command is something like tfpt.exe online /adds /deletes /modify /recurse . (check the help of the command)
Check-in.
Then you'll have the relationship between both branch and the content you want in both.
Have a look at TFS Integration Platform