Is there a way to backup just the source control component of a team project and restore it into a different TFS server? We setup a TFS 2010 server for RND, but decided to use it's source control manager for a development project. We did this so the developers can learn how to work with it before we use it on a much bigger project. Now, we need to blow away the server since it is a VM for RND. We're going to setup a new TFS server for production. I don't want to lose the source code history.
Yes, you can use the TFS Integration Tools to migrate source with history for one or more Team Projects to another server. It is very easy to use.
TFS Integration Tools Download
I hope this helps
Mike
Use the features built into the product. In Dev10, collections were added so artifacts (including source) would be portable between TFS servers - leverage that. Pilot projects were a key scenario for portable artifacts and a justification for collections.
Dettach the collection from the VM TFS instance. It's available from the collection node of the admin console.
Backup the database from the database you dettached.
Deploy the new real server (non-VM).
Restore that collection database to the sql server used for the production instance.
Using the administration console collections node, attach the collection to the newly deployed TFS server.
Now you have the source available from the prototype period and you have a new production collection available for the new production instance.
BTW, in Dev 11 (you can get build conference CTP or beta soon) TFS upgrades the collection on attach so if you deploy a Dev11 TFS server, you can attach that prototype collection and pull it forward.
Related
My company is using a TFS 2013 (Update 4 = 12.0.31101.0) server for development. I was tasked with migrating the TFS server to VSTS but realized I had to update to TFS2018 to be able to use the current migration tool.
My boss obviously didn't like the idea of performing "open heart surgery" on our productive environment so we created a back-up of the SQL Collection-Database (by creating a dump using Management Studio) installed a Trial Version of TFS/SQL Server in a VM (VirtualBox) and tried importing the back-up.
Using the built-in import tool (TFS\Tools\TfsRestore.exe) I imported the old DB into the SQL Server, which actually worked really well, looking at the DB in ManagementStudio everything that needs to be there seems to be there.
However, trying to attach the Team Project Collection in the Team Foundation Server Administration Console I simply can't find it. I List Available Databases and the only one it finds is the DefaultCollection that was created during installation of the server.
I made sure that the versions are the exact same version, only difference is the License which is a real License on our production environment and a Dev License on the VM.
Anyone got an idea why this is happening? Maybe some way to get a more detailed Exception?
Edit: Trying to use the TfsConfig registerDB command throws an expection:
TFS30040: The database is not correctly configured. Contact your Team Foundation Server administrator
First, please make sure you are a member of the Team Foundation Administrators security group and a member of the sysadmin security group for any SQL Server databases that the new Team Foundation Server uses.
Usually this kind of issue should be solved after giving proper database permissions to the user.
Besides, after the configuration you can try RemapDBs to redirect TFS to its databases.
Back to the error: TF30040: The database is not correctly configured. Contact your Team Foundation Server. Here is a similar thread for your reference: TF30040: The database is not correctly configured
Moreover, you could also check the event view on your VM, if there are some more detail error message for troubleshooting.
Did you detach the collection in the TFS admin console before taking the backup on your 2013 server?
When you detach the collection is moves all of the relevant data from the TFS configuration database in to the collection database. You can then take a backup of the collection database and restore it to the new SQL server instance.
Note that detaching the collection will take it offline until the backup is complete and you re-attach the collection.
Then the new version of TFS should be able to see the collection and attach it. This will copy the configuration data to the new configuration database and you'll be able to bring the collection online.
So steps are
Detach collection in TFS 2013
Take backup of the TFS 2013 collection DB
Re-attach the TFS 2013 collection so that users can continue to use the collection whilst you test your upgrade
Copy the backup to the 2018 server
Restore the backup
In the TFS 2018 Admin console attach the collection
Once you're happy that the upgrade will go smoothly repeat the process but skip step 3.
Managed to do it by following this guide : https://cromwellhaus.com/2013/08/restoring-tfs-2012-to-sandbox/
Short Version: I was missing the config database, it was quite easy once I was using the old config.
I found articles on GIT back up and restore but I did not find any on Microsoft TFS Scheduled backup for GIT version control.
This document describes on how TFS's traditional versioning can be scheduled for automatic back up. Configure a backup schedule and plan for Team Foundation Server
However, I did not find any link where I can read that "GIT repository is also included in schedule". I am not a TFS expert and I do not have access to TFS server to verify in person. So any help is appreciated.
The tutorial you are refer which is Scheduled Backups tool. It' a build-in tool on the Scheduled Backups page in the TFS Administration console.
It' the whole database back up not only referring to source control, but also work items, pull requests, builds, test plans or anything else that the service offers.
As a limitation, you need both an administrator for TFS and a member of the SQL Server System Administrators group.
And no need to to verify in person, it's under SQL server, when you want to use the backup, just restore the database.
If you are actually using the online VSTS . For now there is no build-in tool and got a uservoice:
Provide a backup service for Visual Studio Team Services
https://visualstudio.uservoice.com/forums/330519-visual-studio-team-services/suggestions/5339461-provide-a-backup-service-for-visual-studio-team-se
However if you just want a git repository(source code) back up, you could use some 3rd-party tool to achieve this:
We use the VSO Rest API to query our VSO account and get all the data
we need. Since in VSO you can only have one Team Project Collection,
we retrieve all the team projects of the default collection. Each of
these team projects can have multiple repositories that need to be
backed up. A folder is created for each team project and saved to a
location on disk that can be configured in the app.config. When the
team project folder is created, the task loops over each repository in
the team project and creates folders for each repository.
Source Link
You can also fork it on GitHub here. Certainly, you should also be able to use this for on-premise TFS also use the API, just need to change some part.
TFS is implemented the way to keep Git repositories in the SQL Server database, too. Thus, when you follow the instructions from the article you reference, the source code will also be included in the backup, no difference whether it is TFVC or Git.
I am not familiar with TFS, however the scenario that I will be coming across is that I will have a branch of source code stored in Visual Studio Team Services (was TFS Online) and locally I will be running TFS 2008.
Would there be any issues pulling the code from Team Services and merging with TFS 2008?
You won't be able to bind the code (solution and projects) to 2 different TFS servers. If you're using the online version of TFS what reason would you have of also trying to store the code in a local repository?
You definitely won't be able to merge the code between the different servers. TFS is a centralized version control system and merge operations need to be handled and tracked by the server.
You could theoretically Manage the code in one of the TFS servers (i.e. have the solution bound to TFS online) and manually manage the code in the other server. However TFS 2008 only supports local workspaces which means that it will make files read only if they are not explicitly checked out. This will cause you no end of pain.
Even if you did it the other way round (made the local TFS server the "master") you will almost certainly create yourself a load of problems as TFS simply isn't designed to be used this way
Also TFS 2008 is pretty ancient and unsupported.
EDIT:
The typical TFS workflow is.
Create a development branch on the server.
"Get" the code to a local folder on your dev machine (called a workspace).
"Check out" the files you need to modify from your branch or "Add" new files as needed.
You should regularly "check in" files to your branch to make sure your changes are saved on the server.
When your changes are complete then "merge" the code from the development branch back to the Main branch.
The code is stored and versioned on the server, but your changes are made on your local machine. To interact with the server you use the Team Explorer plugin in Visual Studio. Modern version of Visual Studio have Team Explorer built in.
If you're using the online version of TFS then you'll want to use Visual Studio 2012 or above.
If you're planning on Forking the code and do not plan on committing your changes back to the server, then you're probably better off using something like Git. You could use Git-tf or Git-TFS to pull changes from TFS and then that would make merging a lot easier and you could use your local Git Repo to manage your own changes
we are a team who would like to replicate the TFS from one site into another site. Both are in different domain and cannot communicate in any means. Please suggest the best practices of the same.In addition I am also looking for a standalone tool to give me a detailed report of the TFS environment(which includes the work-items, etc) along with the SQL server attached to it. The intention is to replicate the same environment so that a full backup goes through fine.
You want to setup a complete clone of your environment in another site, disconnnected from your. Some key points follows:
You need a proper backup of the current TFS data, see Backup TFS
Size the target environment in terms of disk, memory, network, etc.
Install on the new site a compatible SQL Server version
Install on the new site the same (or newer) TFS version
Study the instruction to Clone TFS and apply them on the new site
Plan for changed environment: Active Directory domain, user accounts
Topology could be different, you have to rebuild you Build and Test infrastructure or, at least, properly remove the old references from the new site
What you are wanting to do is not possible.
You will need to put your TFS server somewhere accessible to both locations. I would recommend either VSO (TFS.visualstudio.com) or a custom IAAS instance and domain.
is there a (simple) way to move a single TeamProject from one server to another? Including source code, work items, documents, project site...
We don't want to move our server from one machine to another. Just a single project from server A to server B.
You have two options
You can use the TFS to TFS migration tool: Click Here. This doesn't include the WSS project site.
Or you can backup your TFS db and restore on a new TFS instance, then use the TFSDeleteProject.exe tool to remove the projects you don't want.
The latter option is the easiest, but will not merge the backed up projects with any existing projects on the target instance. Existing projects will be lost. WSS sites can also be moved in this manner as well. See How to: Back Up a Team Foundation Server
The TFS to TFS migration tool is obsolete. The features you are looking for is part of TFS Integration Platform.
Goto http://tfsintegration.codeplex.com/ for more info.
In TFS 2010 you can detach the Project Collection database using the TFS Admin Console and then re-attach it to another TFS Server.
http://msdn.microsoft.com/en-us/library/dd936138.aspx
If you want an entire Project Collection to be moved from one TFS server to another:
1) Detach the collection via Admin Console.
2) Backup the Tfs_SomethingCollection database using SSMS, then restore it to the other database server.
3) On the second TFS Admin Console, attach the project collection. It will show up as an available collection to attach just because it has been restored in the second sql server instance.
I did not migrate the Tfs_Configuration database. In my case I was not utilizing reporting services, build services, or sharepoint.
I hadn't installed the second TFS server and was wondering, what options to choose when installing, and if you should install it after or before restoring the migrated DB(it doesn't really matter): Install TFS on the second machine. If TFS and its database instance will be on seperate servers, then choose Advanced configuration and specify the name of the DB server instance. When you have an opportunity to create a DefaultCollection, then opt to skip that step. The install will create a new Tfs_Configuration DB on the new server. Then follow the above steps to migrate the collection DB to the new DB server instance and attach it.
Programmers will need to add the new server to Team Explorer, and hit Change Source Control... twice in a row for each solution. Make sure the local path mappings are correct, and then Bind each solution/project.