I am planning to soon migrate a couple of Collections from a on premises TFS 2017 server to a on premises Azure DevOps 2019 server. These collections have multiple Git repos, no older VSTS style code repos.
I've found all sorts of good documents covering how to migrate the collection- and I am able to do that with ease. I took snapshots of my old and new servers and did a temporary test move over a weekend, everything came up just fine. I then reverted to the snapshots.
Does anyone know of a good document or URL for me to provide as instructions to my 20+ developers for them to reconfigure their Team Explorer in Visual Studio? The Collections on the old server will be detached, so there's no need for them to continue to have the old server configured. I don't want anyone to have to completely switch to the new server in a way where they lose any git branches that they only have local (not pushed up to the server.)
I myself only use TortoiseGit to interact with the git repos. I can see in my git repos, I go to the .git folder and change the URL in the file named "config" and the repo is switched over painlessly.
Almost all of the devs only use Team Explorer. If anyone knows of a good guide that I can walk them through with to make the switch from within Team Explorer instead of having to edit text files and registry keys, I appreciate it.
Thanks!
If I understand you correctly, you are looking for guides to connect your devs' Team Explorer in Visual Studio to the projects in the new on premises Azure DevOps 2019 server.
You can check the documents provided in Microsoft site Connect from Visual Studio or Team Explorer.
For more detailed steps you can check out this thread.
You can ask your devs to follow the steps in above thread to add the URL of the new server to Team Explorer. Then they can switch to code repo of new server.
Related
I have got a project in an old org (from VSTS), that I want to move to my new one.
I can't see any options in Azure DevOps on migrating projects, or any information on the interwebs.
Anyone know how to do it?
If you just need to move repos, you can use the built in clone functions:
Go to the Azure Devops source repo -> Files
Click "Clone"
Choose "Generate Git Credentials"
Create the target repo in the target Azure DevOps
Choose "Import a repository"
Use the URL and credentials from Step 3
Done
This is not supported today. But this feature was planned to develop: make it possible to move a Team Project between Team Project Collections
If your Azure Devops project only tracks code versions using a single Git repo, hence no boards, user stories, tasks, pipelines, etc. then you can do the following:
Clone your project repo.
For example with Visual Studio.
You don't need to clone if you already have a local repo.
Destroy the association with the remote.
For this typically, you need to open a command line prompt in the folder that contains the .git database folder, most likely the solution folder of Visual Studio and type git remote rm origin.
Here is an example using git bash showing the content of the solution folder, including the .git database and the *.sln Visual Studio solution file:
Open the solution with Visual Studio if not already done.
It should now show that you have many commits waiting to be pushed to a remote. For illustration purpose, my toy project only have 8 commits in total.
Click the up arrow and choose your new remote, say a brand new Azure DevOps project, in the organization of your choice, then push.
You are now done cloning the project in another organization. If needed, then destroy the project in the old organization to complete the "move" operation.
There are 3 projects that I know of to achieve this.
A paid for option by Ops Hub -
OpsHub Visual Studio Migration Utility
An open source tool that requires making changes to the work item process template - Azure DevOps Migration tools
An lastly an Unofficial but still written by Microsoft tool to create Azure DevOps project templates - Azure DevOps Demo Generator & extractor tool
With the last one (the Demo Generator) you extract the project as a template, then apply it to the new organisation. As it is a tool for demo's there is no support provided and in my experience it works for simple projects but falls over on anything complex.
Expanding on others' answers, this post regards Pipelines.
Azure DevOps API
Migrating nearly all aspects of a project across organizations is doable, but it is a lot of manual work using the Azure DevOps API. The link below shows you all the end points, variables, etc. From there you'll probably want to write a Power Shell script and do a couple test runs to a dummy Organization.
https://learn.microsoft.com/en-us/rest/api/azure/devops/?view=azure-devops-rest-6.1&viewFallbackFrom=azure-devops-rest-6.0
In App options
If you avoid the API, there is no way to migrate pipelines that preserve build or release history, but you can preserve your configurations and processes by going into your Pipelines and selecting View YAML. From here you can either take this away as notes to recreate the GUI steps in your new org/project location, or actually adopt the YAML standard in your git repository.
I do not believe there is a way to migrate pipeline variables outside of the API. However, you can move the variables to Azure Key Vault and change your pipeline settings (YAML) to reference values from key vault. This is not a large amount of effort and is a nice process improvement.
Lastly, if you have any locally installed pipeline agents for releases, you will need to run the Power Shell script for your new organization on the boxes. Very simple 5m step, but right now the Agent Pools are not sharable across organization.
As #Frederic mentioned in his answer, we can actually easily do it with Visual Studio. I have done this without Visual Studio. The steps involved are below.
Add a User to Both Organization
Configure SSH Key
Update the SSH Key in Source DevOps and Clone the Repository
Check out all the Branches and Tags
Update the SSH Key in the Destination DevOps
Remove Old and Add New Origin
Push all the branches
The commands and detailed explanations can be found here.
BTW, if you need to change the entire Devops Organization tied to your personal Tenant (E.g. VS Enterprise Subscription) and move it to new Tenant, you can change the AAD and point it to the new one e.g. your EA Tenant on Azure commercial cloud.
Before you switch your organization directory, make sure the following statements are true:
You're in the Project Collection Administrator group for the
organization.
You're a member or a guest in the source Azure AD and a
member in the destination Azure AD
You have 100 or fewer users in
your source organization. Otherwise you will have to open a support ticket.
You may have to add the users back in destination org if they do not exist becuase they will loose access the moment you switch the AAD.
you could just download as a zip file and then download it to the destination repo
My company has used a cloud TFS host for many years. Now the host has disappeared from the internet and a lot of code and all history has been lost. There are people working on it so it might be solved but I anyway need to fairly quickly set up new source code handling in Visual Studio Online and need some hints on how to do it.
The current solution was set up long before I started and for various reasons I am currently the only developer. It might change in the future but there will never be more than one developer for each visual studio solution.
I work with many small customer specific projects in Visual Studio (windows application, windows service, WebAPI, SSRS, SQL, Entity framework). The average size of a project is maybe 20 hours from start coding to deployment (there are a few larger projects as well). New features and bug fixes are sometimes added after deployment (can be years later) but that is usually 2-6 hour projects.
The current process has one TFS project per customer and each contain at most a handful Visual Studio solutions. There are no dependencies between the solutions and common code is handled with NuGet.
We had around 250 projects in the cloud and even if I so far only recovered 50 of these, the ones I had locally, we will sooner or later end up with similar numbers. Total size was in the region of 30GB (a lot comes from TFS by default checking in the nuget packages folder)
For most projects there is no need for workitems, kanban, reporting and other ALM features. Only developers will ever use visual studio online. I would like to work with a branch/pull-request/merge process. Coming from Git/Mercurial I have never felt comfortable with TFS.
So my questions are now:
What is a good way to structure the projects?
Single VSTS-project for everything
A VSTS-project for each customer (as today)
A VSTS-project per Visual Studio solution
What is a good way to structure the repositories?
One repository for everything
One repository per customer
One repository per Visual Studio solution
How does Visual Studio and the online portal work with hundreds of projects/repositories where 90% are not active. I usually have 3-5 instances of Visual Studio running with different solutions at any time.
I have read a lot of recommendations but they all seem to deal with long-lived projects and/or team of developers.
My main concerns are:
How much work it is to add a new customer or visual studio solution (happens weekly)
Getting started time. Sometimes an external developer is involved. It is not common but when it happens I don't want them to spend a lot of time on clone/pull (security is not an issue)
Standard. I want the process to follow standard/best practice as much as possible to make it easier to document for other developers. e.g. not encoding information in names of projects or forcing a folder structure.
I will suggest:
Create projects from each customer. Such as you can create projects with customer name like WebAPI, SSRS, SQL etc.
Since a VSTS project belongs to a certain customer related. So all the repositories in the team project should related to the customer. The structure for the repositories can be: different repositories for each case/solution of a customer.
There are only two kinds of version control system hosted on VSTS/TFS: Git and TFVC. And it seems you are familiar with Git and Mercurial, so you can use Git VCS for your projects.
Git repositories hosted on VSTS works as other remote repositories like github, bitbucket etc. it’s bare repo without working directories. So the solutions are not stored but the checksum between two versions and it stored with sha-1 value (40 char). And for most time, you work in local repo (no connect/communication with remote repo). Only when you clone/pull/push, your local git repo will communicate with remote repo.
Project(s) structure: Single project for everything.
Repositories structure: One repository per VS solution
Regarding VS work with these projects/solutions, you can close a solution, then open another solution (You can’t open multiple solutions at the same time in the same instance of VS), you also can just open the file in VS and edit. Regarding commit and push, you can use Git command (e.g. git commit, push)
You need to add them to VSTS when developers are involved, and they need to clone/pull source code from remote.
I am trying to see how the OpsHub migration tool works before I perform real migration.
And hence I am trying with a on premise TFS instance and a trial created Team Services (was Visual Studio Online) instance. but when I finish configuring the stuff and it start to validate all the settings put in, it is giving error for Team Services Project Collection URL. It is taking collection URL as
https://********.visualstudio.com/********
where as it should only use
https://********.visualstudio.com/
Not sure how to get over it and now fully stuck.
This is caused by the change in VSTS:
Collection in the domain
Your Team Services account URL just got 18 characters shorter. We’ve
removed “/DefaultCollection” from the path. While it’s small, but
welcome change. It’s the beginning of a larger journey to how we
structure accounts. Learn more here.
Note that existing accounts will still give out the longer URL for Git
Clones in the Code hub. This is because to use the new shorter URL in
VS, you will need to reconnect Team Explorer using the shorter URL.
Today you either need to use the long or the short URL for an account
in VS, you can’t intermingle. Once we have enough clients updated such
that they just work seamlessly with either type, we’ll change the
default Git Clone URL to the shorter one as well.
Last but not least, we have a set of Release Management improvements.
Please download the latest version of OpsHub Visual Studio Migration Utility and then try again.
A similar issue here: OPS Hub - unable to migrate project.
I'm in process of migrating my open source project from VS Team Services to GitHub (in hope of having actual contributors at least).
Migrating git repository was easy, but now I have a problem of migrating issues.
I don't know how to migrate issues.
I really like Team Services board. Can I get something like this in Github?
For Question 1, there isn't any tool or simple way to migrate the VSTS issues to GitHub as I know since the issues in VSTS are work items that use a totally different template with GitHub. If you have large amount of issues need to be migrated, you may create an application and use VSTS Rest API and GitHub API to do this.
For Question 2, GitHub does not provide Kankan board feature by default but you can get it from some other service. For example: waffle.io
I'm advocating using Visual Studio Team Services for our source control solution, and have actually started doing so. However, my manager, who is somewhat apprehensive when it comes to cloud-hosted storage and services, wants to know what our contingency plan is in the event of Team Services ceasing to be accessible for whatever reason.
I've pointed out that we have our source code on our developers' computers, in their mapped work spaces, but admittedly if we ended up with just that and no access to Team Services we'd certainly be in a bit of bind. They might all be working on different parts of the same solution and we wouldn't be able to check all of their changes back into the central repository or merge changes made in separate branches. We also wouldn't have access to the comments associated with previous check-ins, or our backlog, tests, etc.
So, the question is, is there a way to backup everything that we're hosting in Team Services so that, in the event of something going wrong, we'd be able to restore all of that to a locally-hosted installation of TFS (or somewhere else)?
I'm a bit late to the party but we developed a Team Services backup tool. We scheduled it as a scheduled task and it runs once a night. It then just clones all our repositories to disk.
Taken from this blog:
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.
You can also fork it on GitHub here
There's no out of the box backup ability.
Now, if you are only referring to source control, and not work items, pull requests, builds, test plans or anything else that the service offers, then I'd suggest you migrate your code over to git.
With git every developer will have a complete copy of the source repository, including all history and commit comments. From there, it's a simple task to push the git repository to a different git hoster (such as bitbucket or github) and make them your new centrally hosted git repository.
On a historical note, Visual Studio Team Services at one point offered a data export for a period of time. You might want to add a vote or three to this related UserVoice idea to help raise the importance of the feature with Microsoft.
Side comment: The business risks in using Visual Studio Team Services will come from either Microsoft shutting down the Visual Studio Team Services service or that the underlying Azure infrastructure has such a catastrophic failure that your Visual Studio Team Services account is unrecoverable. Both of those are extremely low risk, and very likely lower than the risks you'd have running TFS on-premises, in your own data centre, unless of course, your infrastructure and staff are better than Microsoft's :-)
Not a full VS backup in terms of a restore of service. But you can take a full Zip from root down using the Code web site. Right click the root folder and has a zip download option. Pretty neat feature.
The easiest way to back up everything is to use something like the TFS Integration Platform to periodically pull off all your data into an on-premises TFS solution. I've set this up using an Azure VM that we turned off when we weren't actively backing up, which makes it really low cost. For more info on using the TFS IP with Team Services, see this: http://nakedalm.com/migration-from-tf-service-to-tf-server-with-the-tfs-integration-platform/