I have backup of TFS databases and I want to get my code files from it. Is it possible? If so, then what exactly do I need to do? TFS Version: 11.0.61030.0 (Tfs2012.Update4)
Whatever investigation I have done so far, it seems that the only way to restore the files is to install TFS 2012 on another machine, restore the database backups on that machine. And hopefully afterwards I should be able to download the files from this new TFS. I wanted to verify my procedure because I need to know if there is something missing in my understanding before I start the task.
Yes restore is the way to go, but you must be careful at some important details. I write as I remember:
Use the same version of TFS for the new environment.
The new environment is in the same Active Directory domain. If you are in a workgroup, must add additional steps to make, at least some, accounts match.
Restore from a marked transaction (this is done by the built-in backup/restore tool)
You will have two live system with the same identifier: this may confuse clients. To avoid run the tfsconfig ChangeServerID command.
If you restore the Configuration DB, must run TfsConfig RegisterDB.
For getting code this is enough, but consider that the new environment is still pointing to existing resources: build server, lab management.
If the TFS instance was already used, more steps are necessaries, like cleaning cache on AT.
I do not remeber a complete guidance: there are many variations on this topic. Make sure to study the content of Restore a deployment to new hardware
Related
My company is considering upgrading our on prem TFS 2017 update 3 to the latest Azure DevOps Server (notably, the on prem variety).
During discussions about that possibility, one key stakeholder claimed that if you upgrade, all of your build and release pipelines would have to be rebuilt from scratch. We have a healthy number of build and release definitions in TFS 2017.
I have looked for the answer in the Microsoft documentation about what exactly gets upgraded, but unfortunately I can't get the level of granularity which would prove or disprove the above claim. On the surface it would seem like a horrible upgrade story if it were true. But I also understand that designs and architectures change and upgrades aren't always possible.
Could somebody let me know whether the build and release pipelines can survive the upgrade more or less unscathed? Knowing this would be a valuable data point as we work toward a decision.
Thanks in advance!
The vNext build definitions and the release pipeline I would expect would be pretty lift and shift. Depending on the tasks that you have defined, they might no longer be supported or there might be new versions. The UI will let you know that new versions are available.
A lot of the new focus is building out the features for the YAML build definitions. If you want to leverage those, you'd have to do a lot more rework of converting those vNext tasks into YAML. But converting is not really a hard requirement.
You mentioned that you aren't using the XAML build definitions, but if you happened to be using them, I would image that is where a lot of the rework comes in. Having done that in the past, I can say it is a pain if you have to do it.
all of your build and release pipelines would have to be rebuilt from scratch.
I've tested it and it won't lose any data after upgrading. We should use scheduled backups to ensure that we always have backups in place in case something goes wrong.
we can use that new hardware to do a dry run first, and then we will wipe everything clean and use it again for the production upgrade.
For our dry run, the steps for our upgrade will be:
Copy recent database backups to our new SQL instance.
Install TFS 2015 on our new application tier.
Use scheduled backups to restore the database backups.
Run through the upgrade wizard, being sure to use a service account which does not have any permissions in our production environment. See Protecting production in the dry run in pre-production document for more information.
Optionally configure new features which require changes to our existing projects.
The production upgrade steps will be quite similar. There the steps will be:
Take the production server offline using TFSServiceControl's quiesce command. The goal here is to ensure that the backups we use to move to our new hardware are complete and we don't lose any user data.
Take new backups of each database.
Copy the backups to our new SQL instance.
Install TFS 2015 on our new application tier.
Use the scheduled backups wizard to restore the database backups.
Run through the upgrade wizard, using our desired production service account.
Optionally configure new features which require changes to our existing projects.
You can refer to this doc for more details.
We have TFS server to be moved to a new Hardware please suggest the steps involved and the best approach.
The DB instance will also change will just Backing up and Restoring the Collection DBs be fine? and attaching these collections to the New TFS setup?
Thanks & Regards
Just as DaveShaw suggested in the comment, there are official tutorials in MSDN, you could simply follow the suggestion there. The steps are very clear and detail
Restore data to a different server than the current one for TFS
If you also want to do the version upgrade something you could pay attention such as :
Pre-production upgrade is just a dry run of your upgrade in a production environment.
Usually we use this to test your upgrade. This process test upgrades the databases. You can use this to simultaneously test your TFS on another hardware while continue to use your existing older TFS up.
Once you are ready for upgrade, restore the databases again and just use the Production Upgrade scenario during the server configuration wizard.
Besides, suggest you directly move the changes in the production environment later, a tutorial for In-place upgrade to for your reference.
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.
So, we're using continuous integration in our current Team Foundation Server 2010 setup, and so far it's working great. We're doing shelvesets, the build is running on the Build Manager in TFS, and it's also running our MSTest unit tests for us.
My question is, and I can't seem to find any information on this, is how to move the "build unit" that is created by the Build Manager on TFS to another server?
Aka, how do I "promote" this build to our QA, staging, etc... environments?
Before, we've were using VS2010's Publish Web feature, which allows us to set up publish "profiles", and each profile can have a different web.config related to it. This is really useful for anything we keep in our config files, like db connection strings, paths to app servers, etc... changing automatically based on our Publish Profile. We choose the profile, build locally, then use the "Publish" button to move the entire app to another server.
This setup worked great for when there were two of us working, and we were using TFS for just its source repository, but now the builds are happening on the TFS server.
What I'm looking for is a way for when TFS does the build for us (it's no longer being done locally on our machine, but by TFS Build Manager) to:
take into account which "publish profile" to use. This will effect what web.config is used and other items you can associate with a profile in your IDE.
once the build is created, to find a way to "push" the build to one of our other servers (QA, Staging, production) FROM TFS.
I don't even know if that is possible or not. Maybe it's still a manual job to take the build created on TFS, and copy it over by hand, and unzip the project/files into the correct file path on the deployed server? Or maybe it's part of the workflow in TFS, and I still have yet to find it.
This is surely possible already from TFS. Read the posts from Vishal Joshi on this topic, starting with: http://vishaljoshi.blogspot.com/2011/07/documenting-key-end-to-end-deployment.html
The solution I came up with is I wrote my own build handler for TFS, and use that code to push builds to our different environments. Here is the link I used to help me: http://geekswithblogs.net/jakob/archive/2010/10/27/devleoping-and-debugging-server-side-event-handlers-in-tfs-2010.aspx.
If anyone wants more specifics, just contact me and I'll be glad to help you.
Let's say I have my TFS team project setup the way I want it, and all the code between my machine and the team project is in sync (i.e. if I do a get latest it says everything is up to date).
What I would like to do is test whether or not I can pull the project back down to my local machine from TFS source control have everything work properly. By work properly, I mean I'm able to build all the projects, run the web sites, etc.
I thought what I could do is just blow away the code on my local machine and then do a get latest. But TFS seems to think that my local machine and TFS are still in sync (this is a bit different from the way Visual Source Safe worked).
In a nutshell, I'm just trying to test whether or not if another developer were to pull this team project down to their machine, that I know the project is setup correctly with all the necessary dependencies, etc. such that the other developer could build and run the project. But since I only have one machine to test this with currently, I need to do this test on the same machine.
The only way I've found to do it is to use "Get specific version" and force it to overwrite existing files, but it seems like if I delete the stuff off my hard drive, it should know when I do a get latest that "hey, the files aren't there anymore, I need to pull them down".
Any ideas on how I can do this? Thanks.
Not withstanding the answer above highlighting the merits of having an automated build process and continuous integration...
The easiest way to validate what you've checked-in is to create a new workspace with the same folder mappings, albeit to a different location on your hard-drive. You can then 'Get Latest' into this new workspace and confirm that everything builds locally, this should prove that:
The correct versions of existing files are in source control
All the required files have actually been added to source control
Alternatively if you'd rather not check-in your changes until you've validated your pending changes, then your best bet is to 'Shelve' all your changes (ticking the box to undo your pending changes), and then 'Unshelve' that shelveset into a new Workspace and do your testing against that instance of the codebase... or even ask a colleague to pull down your shelveset and do the validation (typically this called a 'Buddy Build').
TFS is a little different that VSS in that local workspaces are maintained so that every file doesn't have to be compared with every GET. In addition to removing the code from your development machine, you should also delete your local workspace. Check out "Working with Version Control Workspaces" on MSDN:
http://msdn.microsoft.com/en-us/library/ms181383.aspx
Really, though, the best way to make sure that your code can be pulled down and built easily is to create an automated build in TFS for continuous integration. That way you know immediately if you have done something that would make the solution un-buildable.
Check out the overviews of Team Foundation Build on MSDN:
http://msdn.microsoft.com/en-us/library/ms181710.aspx
The answers above are good. Except it will not completely test you entire scenario. If you have references outside of your solution (such as dll in the GAC, or dll from an SDK installed on your machine), creating a new workspace or deleting and getting latest code won't found those problems.
The only way to make sure is to pull down the code on another computer. If you don't have another computer handy, you can use a Virtual machine.
Do Get Specific Version and specify the latest. This will force TFS to download everything, ignoring the current synchronisation status.
TFS uses your workspace to know what is synched between the server and local.
I don't think there is an option to make Get Latest to behave like you want (Get Specific Version and specifying Latest Version and Overwrite).