I'm using VSO xxx.visualstudio.com. We have to migrate with history to yyy.visualstudio.com. I know there is no direct tool. Looking for good approach or solution.
Unique Difference with, below question:
Visual Studio Online migration (VSO to VSO)
Export Source code with work Items
TFS Integration Platform tool is not working.
OpsHub company is taking too long to reply.
You can use the TFS Integration Tools to move TFVC code and Work Items from one Team Project to another regardless of TFS/VSO version.
I have done this a number of times and it works pretty well..
Related
We're looking at moving from TFS to VSTS. However, one of the features I rely on is the ability to see which developers have got code checked out, when it's getting checked in, and to which branch. I need to see this at the collection level, not per project. Does this functionality exist in VSTS?
Tks
No such built-in features in Azure DevOps (VSTS).
However you can try below workarounds:
To see which developers have got code checked out, you can use the
tool Team Foundation Sidekicks which can retrieve the status
locked/checked out by other users. But the latest version is Version 6.0 only for Visual Studio 2015. Based on my test it's also available for VSTS. Please reference my answers in below threads:
Is there a way in Visual Studio and TFS to view items checked out to local workspaces?
List of checked out files
For when it's getting checked in, and to which branch, you have to
navigate to the specific repository to check the changesets which
include the history. You can also try calling the REST API
(Changesets - Get) to get the information.
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'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've tried running the OpsHub migration tool to migrate TFS2013 on prem to VSTS. There's a couple of quirks I've managed to iron out, but the big two are:
Tasks are unparented in VSTS, the link wasn't preserved?
Tags aren't migrated
Has anyone else had this issue?
I believe that OpsHub are now charging extra for "preserving links" both between work items and between code and work items. Additionally I would not be surprised if Tags were on that list as well.
You should switch to the TFS Integration Tools, which are free.
They are a lot more complicated, cumbersome, and buggy but they work... Although there is only an old release it works with VSTS.
We are sorry to inform you but in the .000 release of v2.0 of our tool, there was a regression in Links and Relationship.
Can you please install the latest patch release ie. 2.0.0.002 from the Gallery and re-do the migration.
Links between WIT is still a part of the Free Version of the utility. :)
And we plan to support the 'tags' very soon for VSTS.
I'm using Visual Studio Team Services xxx.visualstudio.com. Now I have to move entire solution with history to yyy.visualstudio.com. Please let me know how to proceed.
I'm using Visual-studio 2012.
If you need to move the data to a new about that already has data then you need to do a migration. Look at the TFS Integration Tooling.
I recomend that you drop history if you are using TFVC. Git can be migrated easily by simply adding another origin.