So I've been trying to perform a migration (code only, no work items) of a medium sized project from an on-premises TFS2010 to VSTS using the OpsHub tool. My user is an administrator on both sides, and the migration runs and completes without tossing errors.
The problem is that it just doesn't do what it says it will. I spent a long time mapping the users from TFS to VSTS during the setup, but it completely ignored that mapping and assigned every single changeset to my VSTS account. The docs also say that it should preserve the original TFS check-in time in the comment of the new VSTS changeset, but it never does that to any of them -- the comments are just brought over exactly as they were.
It seems like there must be a setting set wrong in OpsHub to turn these features on, but I can't find any kind of options screen or anything in the tool. It looks like other users are able to successfully map the TFS users to the VSTS users and have it work like you would expect, but I can't make heads or tails of it.
Thanks for any help or advice on this.
If you are using the free version then this feature is not supported by it and same is mention on the visual studio gallery download page, only the commercial version of migration utility supports partial user impersonation, i.e. writing changes as per configured user mapping.
Related
I'm in the process of migrating some source code from an in-house system over to TFS 2015. I'm using the APIs via Microsoft.TeamFoundation.VersionControl.Client etc libraries.
Ideally I would like to also import the history of each item including who made the change and when.
The workspace.CheckIn method allows me to specify the "author" who made the change, but I don't think it's possible to supply the when.
Does anyone know if's it possible to "back-date" a checkin?
You can't change CreatedDate of a changeset. In fact you should not be doing this in the first place.
Even if you manage to change somehow then you will loose the track of when you really created/check in the changeset on TFS.
If you are upgrading older TFS to TFS2015. Which is a full data transfer. TFS sever will also include the back-date changeset. However you are using an in-house system, just the same as checking in code from local development.
So you may have to manually manage the source control history of your in-house system, such as import to a Excel.
We have a situation where at a point in our project's life, we needed to split off work item tracking and source control into 2 separate TFS projects, with the work items being in a VS Team Services project, and the source on-prem in TFS 2013.
The reason at the time being, we needed to grant access for our stakeholders to the product backlog, without them being on the corporate network where TFS is hosted. At the time there was concerns about security of the source code, hence the whole project was not lifted and shifted, just the backlog.
Now we're realizing some of the security concerns were not warranted, and we are missing out on the integration of ALM provided by a single project having both responsibilities, and would like to merge our source control out into the cloud-based VSTS project.
The problem is, the migration tools are overwriting the Work Items in VSTS. Is there some way we could merge, preserving that data, or any alternative to merge these two things together somehow?
I think you're looking at the Team Foundation Server Integration Tools here if you want to migrate source code history. Bear in mind that it's not going to be perfect (data time stamps will not be the same etc.).
If you can get away with it then just stick the latest code in VSTS and consider the on-prem server your archive should you need to go back. That doesn't tend to be too popular so you'll be wrestling with the integration tools. It's not the most friendly thing to use but mostly it will get the job done.
When you configure your session, you will want to choose Team Foundation Server\VersionControl.xml for your configuration. Then select a One-way-migration between your on-prem and VSTS.
You'll need to install VS 2012 or at least the Team Explorer.
Edit Coincidentally I had to do this myself so I blogged about the process here
I’m beginning to consider moving an on-prem TFS 2012 installation to Visual Studio Online. So, one of the first things I started investigating was how we might export our content back out of VSO in the future if we ever decided we needed to. The more I’m looking, the less I’m finding. It seems there was a temporary time period when VSO first went GA that Microsoft offered that capability if you asked to have it done (http://www.visualstudio.com/en-us/news/2014-apr-3-vso.aspx). By implication, that would seem to mean that this isn’t something that is a planned feature of VSO.
Making a commitment to house all of my source and ALM data in a repository I’d effectively be barred from leaving doesn’t sound particularly appealing. Am I missing something, or does Microsoft really not have export capabilities on their VSO product roadmap? It would seem that this would be a show-stopper for many organizations from coming onto VSO, which is a perfect application to put into the cloud IMHO.
For code you can use Git. Even if you start with TFVC, you can use Git-TF. Clone with the --deep parameter to get the full history in a new Git repo, then push back to a new project (Git or TFVC).
For work items the TEAM tab in Microsoft Excel is a very capable export facility for work items, though you don't get links (other than parent child), or attachments.
In the original project, create a query that lists all your work items.
Open Excel, go to the TEAM tab and click 'New List', you should get the option to select your project and the query you just created.
In the Work Items tab select the 'Choose Columns' button and select all the columns you want to migrate.
If migrating to another TFS / VSO project, create that project, open another list in Excel connected to the new project.
Cut and paste all the work items from the original project list to the new project list (excluding the Id column).
Publish.
voilà.
You're right there's no good solution for this yet. However, if you're using Git as the source-control back-end (instead of TFVC), you can easily pull down the entire repo then push it up into any other source control server (non-VSO) with full history.
For TFVC source-control, or work items (or builds, test results, etc), things aren't so easy.
The answer is not black and white: with the TFS Client API you can connect to both platform and read/write as you please. It is not a trivial task, so someone has created tooling, like Brian says. Another option is using the open source TFS Integration Platform: it is complex but with some help you can do it.
What you really must consider and plan is the data model: moving from an ALM Platform to another is never trivial and the complexity lies in the difference of the underlying model and any customization you made.
As long as you do not customize you on-prem TFS, it is very doable, with a reasonable effort to move to VSO and back. In this context customize means: custom workitems fields, types or workflows, server-side plugins; shortly anything that requires code or schema change. Note that you can still customize builds as this is properly managed.
I expect to see more solutions arriving thanks to the new REST API, but it will take time before we see solid products.
So your original question has a positive answer (TFS on-prem -> VSO) using OpsHub, but know what you are doing and, as I write, it is practically a one way journey.
I have a team project that contains n number of branches, and each branch contains a Database folder in the root. The database folder is where developers check in views, stored procedures, etc. We have had some issues with developers checking in SQL Code that was poorly written, introduced performance bottlenecks, and so on. The DBA has asked me to prevent developers from checking in changes to the Database folder until he has had a chance to review them.
I know that I can add a 'Database Reviewer' as part of a required check-in note, but I don't need a database review every time a developer checks in; I only need the database review to be required if the changeset contains changes to the Database folder. I haven't been able to come up with anything worthwhile on Google, so I don't think that this is functionality that is built in to TFS. Could someone point in the direction of how to resolve this, or explain how they resolved a similar problem in the past?
Thanks!
There is no clear cut solution for this, but you have a few options.
Remove the check-in permissions to the Database folder for normal developers and have them send their changes as a Shelveset to the Database guy.
Ask the developers to become more professional and have them walk by the SQL guy to review their code with them, so that they will be more proficient in SQL later (would be my preferred choice is the SQL Guy isn't part of the team)
Ask the SQL guy to join the team and have him pair with the developers when writing complex SQL scripts (that's even better).
There is no option to make the check-in note optional for specific branches, folders or files right built into the product, but by developing a custom checkin policy you could require data to be entered in the Database Reviewed field. Combine this with the Custom path policy to limit this check-in policy to specific paths in source control.
That custom policy would look something like this:
public override PolicyFailure[] Evaluate()
{
if (
PendingCheckin.CheckinNotes.CheckinNotes.Values.Any(
note => note.Name == "Database Reviewed By" && string.IsNullOrWhiteSpace(note.Value)))
{
return new PolicyFailure[]{new PolicyFailure("Database Review Required", this) };
}
else
{
return new PolicyFailure[0];
}
}
Check out this small sample project to see how you can create a custom checkin policy. And the requirements if your Check-in policy needs to support multiple Visual Studio versions.
TFS 2012 adds a Code Review feature which can be made required using a 3rd party check-in policy (again, combine with the custom path Policy to make it required only for certain paths). There are a few projects on codeplex that provide similar features for older versions of TFS. These include Team Review and TFS Review Workflow.
There isn't anything built in to handle this. I think the best way to handle it would be to lock down those folders so developers can't check in there. Create a branch/folder where you can allow the developers to check in there. This would give the DBAs the ability to review the changes before they merge/migrate them.
TFS 2012 includes a code review workflow that could also be used if you could upgrade TFS. There is also a custom add-on called Team Review that works with TFS 2008. It provides a nice workflow but it would still be voluntary.
https://teamreview.codeplex.com/releases/view/40528
Thanks,
Mike
I'd like to know if it's possible (and how, if anyone has ever done it before) to have Mantis Bug Tracker "tickets" automatically imported/transformed into TFS work items.
We use mantis to keep track of development and TFS as a Repo. Every check-in made to TFS must be associated with one work item. Right now, these two systems are not integrated which causes, for example, that the ticket 100 is relative to the work item 497 without no way of knowing that one is relative to the other.
I've looked at TFS Integration Tools but was unable to install it for some reason at this time.
So, how can I have an automation process that "imports" Mantis tickets into TFS work items automatically? Is this even possible?
There is a plugin for source integration which supports Git, SVN and Mercurial (experimental).
https://github.com/mantisbt-plugins/source-integration
I am not aware that there is something similar avalaible for TFS, but it should be no big problem to implement TFS integration based on the framework which is offered by the plugin.