I am having a hard time migrating a tfs2017 update 1 to vsts. I am using microsoft's migration guide however I have managed to migrate a single collection and its users and team account into a vsts account (Dry run), but the issue is I cannot seem to find a way to migrate all the other collections into into that particular account, does anyone have faced situation like this or am I doing something wrong here, Or Is it possible or not, if yes then please throw some light on the possibility.
You can't. VSTS only supports one collection per account.
Your options are as follows:
Combine your existing collections into a single collection, then migrate that collection. This may be more or less difficult depending on the amount of data and history you have, and what amount of that you need to retain, and the fidelity at which you wish to retain it.
There is a concept called Organizations that will allow multiple VSTS accounts to be managed underneath a single umbrella, but it's still in preview.
Per the feature timeline, it's slated for third quarter 2017, so sometime this fall.
Related
I do quite a lot of security reviews on 365 tenants, which I have made an template. This is all written in a WIKI in DevOps. To that I have an Microsoft Planner this is everything taken out in headlines. This I usually go though with IT.
After that I do an report based on this planner.
But would LOVE to automate this process as the report task is so time consuming and a lot of it is copy paste.
I was thinking of changing my Planner and WIKI out with Work Items in DevOps. This way I could document directly in Work Items what IT is reporting and export the Work Items.
It does however (to my knowledge) not scale that good. It seems to me that I would have to create a DevOps site for every IT department/tenant.
Would love to hear from anybody who have experience with this or related to this.
I have tried with Work Items, but could not make it scalable for more than one IT department.
We have a scenario where we need to migrate more than a 100 projects that are in one ADO organization to another ADO organization.
Is there way how to do perform this migration org to org?
We have tried using the Azure migration devops tool by installing it in DEV test lab in A tenant and installed the tool.
Started with workitem migration but couldn't due to the errors.
So is there a way out to directly migrate org to org in two different ADO's?
There is no built-in way to migrate projects from one Azure DevOps organization to another. However, there are a few ways to accomplish this:
Use the Azure DevOps Migration Tools.
Use a third-party tool, such as OpsHub Integration Manager.
Manually export and import the data using the Azure DevOps REST API.
Currently, there is no supported method to move an organization directly to another inside azure devops, and you could follow this user voice ticket for the upcoming feature. make it possible to move a Team Project between Team Project Collections
As already shared in previous answers, there is no direct way supported by Azure currently, to migrate an org from one ADO to another ADO. There are a few third-party migrations tools that support this use case. When selecting migration approach, here are a few factors that should be considered, as these are often over-looked and cause trouble during the migration process:
What data can the migration solution migrate?
As there is no direct (Lift and shift) way supported by Azure to migrate, all third-party tools use ADO APIs to move data. As a result, there will never be zero data loss, e.g., no tool will be able to retain work item ID across ADO orgs. You need to list your must–have requirements (e.g., history, mentions, inline images, source code, work items, test management etc.) and then choose a tool that can meet most of them.
Can users continue to use source ADO, while the migration is going
on?
Downtime adds operational costs and impacts development operations as teams cannot use ADO during ongoing migration. Anticipate downtime required for scenarios which may cause further business disruption.
Time and monitoring required to migrate data?
If the migration tool is migrating projects one by one, it can take a lot of effort and time to migrate the data spread across 100+ projects. Understand how many projects can be migrated in parallel to have a speedy migration and minimize disruption.
What level of skills will be required to use migration tool?
Some tools are a collection of unsupported beta versions of scripts, requiring a very high degree of sophistication. These can be again highly time-consuming, error-prone, and can hinder operations. Analyze what part of migration may require script and involvement from your side.
As captured in the previous answer, OpsHub provides a Migration tool, OpsHub Azure DevOps Migrator (OADOM), which helps you migrate projects from one organization to another ADO organization. It provides rich data migration, including history, attachments, inline images, user mentions, etc., for a wide variety of data sets, including source code, test assets, work items, Area, Iteration, etc.
Please reach out to OpsHub’s Migration Experts to discuss how to migrate the projects from one ADO organization to another.
Our company has recently introduced Azure DevOps to streamline project management process. Currently, 140 projects are created under our organization in Azure DevOps. As and when requirement comes from client for any specific project, we create tasks/bugs for different developers under that project. Currently we use only two Work Item type - Bug and Task.
Now the issue is Management of the company wants to see Project-wise number of "New/Open", "Active" and "Closed" Tasks and Bugs in a SINGLE chart. That means, that single chart must fit consolidated data of 140 projects. If a person views that single chart they must get idea, for example that - Project 1 has 2 new/open work items, 2 active work items and 2 closed Work items , Project 2 has 1 new/open work items, 10 active work items and 3 closed Work items and so on.. This is done so that management in a glance can understand which project is lagging behind for customer delivery. So that they can work accordingly build more manpower for those Projects.
I have tried to create various such charts and widgets with different queries in Azure DevOps. I used widget burn up and burn out charts but it gives data for tasks of single Project only. Also when we add multiple projects to it, it shows summation of completed/remaining tasks for those Projects & NOT Project name-wise completed/remaining tasks bifurcation.
I also tried "Charts for work item" widget but it also fetches count as per- Assignee, State and Work Item type and not project name wise count is fetched.
I don't want to navigate through 140 projects pages to see it's open, active and closed tasks. So please help me out in suggesting the ideas on How can I build a single chart from where we can get all this data? I will be forever grateful for your answers.
Thank you!
You could create a query across projects, select Team Project column in Column option, ad save the query as shared query. Check the screenshots below:
Then add a chart widget to a dashboard, select Pivot table, and set Team Projects, State as Rows and Columns. Check the screenshot below:
You could expand the view to see more details:
https://learn.microsoft.com/en-us/azure/devops/report/dashboards/charts?view=azure-devops#add-a-chart-widget-to-a-dashboard
I'd be slightly careful based on what you've put down because I don't think your management team quite understand what they need, and DevOps can only do so much. I'd be challenging them around the setup of your DevOps process personally because I don't think it's advisable to not have user stories as part of your setup. Although it simplifies some aspects of DevOps, our experience has been that people have been able to group things together better with user stories as well as tasks.
Appreciate it's a good idea to be able to see what's going on across all projects, but I think there are probably further criteria to think about. E.g. do you want to see estimates instead of/as well as the count of the items since that will have a better reflection of the effort required. In terms of completed items and in fact, probably all that you're displaying, again it's more on your project process, but are management genuinely interested in everything? For example, do they need to know that something was closed 6 months ago, or are they just interested in the last month?
I suppose what I'm getting at is you probably need a bit more information from management about what they want to use the report for so you can give them what they need rather than they want. There's a temptation to say you want everything because you don't understand the capabilities of the solution or what you're going to use it for, and my recommendation would be to challenge them on this so you can better present things (giving them what they need rather than what they want).
In terms of what you're looking to do, I'll openly admit I'm not clued up on everything DevOps related but I doubt you'll be able to report at a project level within DevOps. I think what you'd need to do is set up your query, which would look across all projects in your organisation, and then export the results to Excel. From there I'd create a pivot table (or perhaps more than 1) with the data that you need. Have Project names down the left side (row headers), and bring in whatever else you need as columns. I think that's probably a good quick win to get something in front of your management team, and then you could challenge from there - almost picking holes in it so that they realise that the business decisions that they'd make from this may not be fully informed, and suggesting some changes. From experience, it's probably better to consider it almost as a prototype and not get bogged down with a solution at this stage because you may be asked for changes when they can visualise what they've originally asked for. Once management is happy you could look at other solutions to provide the report, but Excel is typically a good starting point I've found in the past when working on something new like this.
On Azure DevOps, I have a set of test cases and every test case has a number of related bugs (from 0 to you better not know :p). The link type here is "Tests".
I would like to sort the test cases by number of related bugs, to make an estimation of the most buggy parts of the software.
I've tried but I only found the option "Number of links" ("Nombre de liens associés" in French).
Thanks in advance.
EDIT: we use Azure DevOps Server, not Azure DevOps Service. Thus, unfortunately I can't follow the steps here: https://learn.microsoft.com/en-us/azure/devops/boards/queries/linking-attachments?view=azure-devops#list-items-based-on-linked-dependents
Sort test cases by number of related bugs on Azure DevOps
For this issue , I am afraid it is currently unachievable in azure devops. Currently, there is no feature of sorting by related work items in azure devops.
Running the following query in the azure devops server, you can get all test cases containing related bugs , but you cannot sort these test cases.
Apart from the negative answer, I think what you want is a good idea! So I post a feature request here in DC forum. Anyone interested in this can vote for it and track it. You could vote that suggestion ticket and share your comment there,The product team would provide the updates if they view it.
You can do that only through customization:
Add a new field like Bugs Count or Active Bugs count. Add and manage fields for an inherited process
Create custom app to fill that field with real count of bugs through REST API. Wiql - Query By Wiql, Work Items - Update
Then you can use a column setting to edit the sort order of your query result.
(Posting the question here as this is the 'community' that Microsoft redirects to with a 'Need advice? Ask community' button. Hope it won't get closed as 'primarily opinion based' or 'too broad')
Hello,
I want to start using AzureDevops in my department for organizing code & work. We're a small team who creates a large number of applications & plugins.
Some of these applications have a very short lifecycle, i.e. we deliver them, and they work for years without changes. Other apps are larger and are updated/fixed across several months or years.
These applications are completely separate from each other in all aspects.
As far as I understand Azure DevOps structure, my department should become an 'Organization' (we can/need to be separate from the rest of the corporation).
I am a bit puzzled about the 'Project' part. Documentation says
In general, we recommend that you use a single project to support your organization or enterprise.
So, let's say we do have one project called Our Apps - where do we then put all the individual application-projects?
As far as I understand, each product (application) that we deliver should have it's own repository (or a set of applications, if they are logically connected).
This is in order to allow a developer to simply clone the repo on their machine and contribute to that product only - without downloading other projects etc.
I need to be able to:
easily navigate/see all the tens/(hundreds?) of applications that we create,
view their separate kanban boards (for those project that do have it, not all of them will)
to see their repositories (Git or TFS), commits etc
see & manage their pipelines
At the moment it seems to me that the only place where I can see a 'list' of what products do we have is the drop down below:
And the only way to see what is going on in the big-enough-to-get-own-board products is by creating a new separate 'SomeApp Team' in the Project (even though same people are in it), so that I can have a board for the SomeApp - and view the boards from here:
Is that the intended way to organize the structure?
Any alternative approaches?
Is there any way to have a 'cross-reposistory' or 'cross-team' overview?
What about creating documentation for each 'product'?
The "one project to rule them all" was coined by Martin Hinshelwood and his blog post from way-back-when explains the reasons and limitations.
With the introduction of Tagging and filtering on the backlog there is an alternative approach within the one-project setup.
Create team for the real teams you have in your organisation.
Create an area path for each major project/product in the org.
Assign the area paths of the projects to the teams who are working on them. This can change over time.
Optionally tag work items with the major project/product for additional filtering.
This way each team sees a complete view of all the work they can pull from. And they can quickly filter the work by tags to remove items from view when discussing specific projects/products.
Also, when teams change their focus from one product/project to another, you can simply change the assigned areas for that team to update their view.
The Plan View extension provides an additional cross-team view across over all the work. And the Dependency Tracker extension can visualize dependencies over time.
You can also use the Epic/Feature/PBI|UserStory tree structure to create additional grouping in your work items. You can customize the process template to introduce a Product level, though for the planning features to work, that would also mean that you'd also have to create full traceability from Product down to PBI|UserStory.
The main recommendation is to try a few of these approaches in a light-weight manner to see how they work and find your own ideal setup.
Another option for cross project visualization is to enable the Analytics Extension and connect it to PowerBI.
As you'll soon figure out, naming guidelines for your Tags, Repositories, Pipelines is going to be very important. Being able to quickly filter to the right level requires this.