I'm a member of one of my colleague's personal Azure DevOps Services organization (I hope I'm using that term correctly). And there's another Azure DevOps organization that we're both a part of. In my colleague's personal organization there's a project I've been working on for a while. My colleague and I both agree that it would be best, at this time, to move that project from his personal organization to our company's organization in Azure DevOps Services. Only, we don't know how to do that.
So, is it possible to move a project (code, wiki, board, etc.) from one Azure DevOps organization to another? If so, how do I go about doing that?
Daniel Mann's answered my question in his comment in reply to my question:
No, it's not possible to move a project between organizations. The
best you can do is employ various migration tools to recreate the work
item data in the new organization, and accept that there is going to
be some degree of loss of fidelity. For example, you can easily move
your repos, but pull requests are simply not transferrable.
Related
How to migrate Boards, Pipeline, Test Plan, Artifacts and Repo from on-prem azdevops server to Existing organization in azdevops service? Is it any different tool available?
The different migration options are explained in the official documentation. There are some existing tool (see this High fidelity database migration option) but do not expect a 1:1 migration, you might loose some stuff in between. Depending on the criticality of your data, it might not be an issue though and could be enough.
The best probably remains to do it manually/using the APIs.
There is no officially supported way to merge 2 Azure DevOps Organisations or an Azure DevOps Server with an Azure DevOps organization.
With the official import tooling each Project Collection on your Azure DevOps Server will be mapped to a new Azure DevOps Organization.
There are all kinds of tools that can replay the history of work items and test plans. You can git mirror repositories from one place to another. You can use git-tfs or 3rd party tools to migrate TFVC history from one organization to another. Azure Pipelines can be exported/imported and Azure Artefacts can be downloaded/uploaded with the native tools for each kind of supported artifact feed.
This process is complicated, cannot be 100% and will cause certain data to be altered or lost. Since work item IDs and changesets and test case/plan IDs are unique per Organization it's impossible to migrate with these ids in tact. Hence all kinds of mapping and remapping is required. Certain dates (like Created Date, Changed Date) can't be overridden and will be reset to the time of migration
I'm trying to migrate Azure Boards from one organization to another. I dont see any documentation from MS for org to org migration.
Thank you Hugh Lin-MSFT for providing the details. Re-iterating here for broader audience.
If you are referring to moving work items from one organization to another, you can use the Excel to export and import the work items to achieve this .
First, you need to create a query to get work items, then install the Azure DevOps Office Integration Tool in azure devops , in Excel click on the Team button and then New List to get data from Azure DevOps to Excel, and finally publish work items to destination organization.
For detailed steps, please refer to this blog.
In addition, another way is that you could think about using third party extension tool like the Migration Tools for Azure DevOps . You can refer to this similar case.
Hope this information helps.
I have two Projects in one Organization (like in the attached image below).
I would like to see the items from both Projects in the same Azure DevOps Board (dashboard).
Azure DevOps Boards (dashboards) show just the items from the selected Project.
How can I add items (User Stories) from both Projects to the same Azure DevOps Board?
(There is pretty good documentation on https://learn.microsoft.com/en-us/azure/devops/boards/?view=azure-devops but I did not find the answer)
How I can add multiple projects on the same Azure DevOps Board?
Just as we know, Azure DevOps Board is associated with an Iteration Path(Agile). An iteration path only exists within the context of a Team Project. So, Azure DevOps Board boards by their current implementation live only within a Team Project.
As a workaround, you can try to use the extension Delivery Plans, with Delivery Plans, you gain tailor-made views across several teams and their development backlogs—stories, features, or epics. You can use these views to drive alignment across teams by overlaying several backlogs onto your delivery schedule:
Check the document Managing project schedules across teams with Delivery Plans for some more details.
BTW, there is a user voice Single Dashboard for Multiple Projects, which is on the roadmap, you can vote and track the feedback from this ticket.
Hope this helps.
You cannot do that. I think you have to use one team project and several teams. Just create separate teams for each project. Azure DevOps will create an area path for each team. Then each team will use their own backlogs. In the default project team you can select "Include sub areas," and then you will see items for all teams (or projects).
Additional links:
Add a team, move from one default team to several teams
Define area paths and assign to a team
We are a small company and are still unsure how to start all this azure stuff.
Ok, we are clear on the technicalities like table storage and queues and all the that stuff, what we don't know about at all is how to set up the organization around developing for our developers. Which/how many azure accounts, shared or individual ones.
So far we've done classic windows development, so everyone has his environment, unit tests run either locally or on the build server (after pushing to mercurial or git), deployment from the build server.
The thing is that we want to use Azure not just as a hoster, but the full set, like blob/document/table storage, event hubs, storage queues, ReliableActors and everything. Things we can't do locally.
What's the appropriate way for azure then? There are about 20 to 30 developers and most have the enterprise msdn subscription.
What is a "company or organisation" account for? Should developers have their own accounts? Does DevOps need their passwords for all the bamboo or jenkins build stuff?
I went through this recently and I can share a few tips here since I'm also not aware of a DevOps specific platform to share this on StackExhange.
As far as organizing your subscriptions go look at Azure Pay-As-You-Go Dev/Test Subscriptions link
or Enterprise Dev/Test link if you are an Enterprise Agreement customer. These are aimed at development teams, you get discounted rates since you don't pay for software licenses that are already included in your MSDN subscription.
It is best to use individual developer subscriptions for exploration, POC etc while running your main dev workload in the Dev-Test subscription. It looks tempting to try and save a buck by spreading the work across multiple MSDN subscriptions to use the credits but I wouldn't recommend it. It becomes a pain to manage 20~30 subscriptions and they can run out of credits and things stop working. If you remove the spending limit on all the subscriptions you run the risk of racking up a huge bill accidently if multiple devs leave VMs on or add premium storage to VMs etc.
As far as DevOps go, use RBAC and Azure Active Directory to manage access and certificates for your DevOps tooling, build servers, release management etc don't use individual developer credentials for this.
And I agree with the other comments, get in touch with MS as well, this is just the tip of the iceberg but it will get you started.
We're completely upgrading our production and development environment from co-located boxes to an Azure implementation and we'll be developing using Visual Studio Online. Up until this point our dev has occurred on a Remote Desktop environment where developers were logging into Windows server and developing on that RDP box.
We want to set this up and we have some confusion about the Account types/set up types.
It appears there are two ways to set up our Azure and two ways to set up our developers. We are a MS partner w/ some MSDN licenses and Azure credits.
So for Azure we can use our existing MS accounts and just set up an Azure Pay As You Go (PAYG) subscription. This was suggested to us initially but it seems weird to have the entire companies Azure environment going through an individuals live ID. Then we saw we can sign up as an Organization now and it uses Azure AD. We have not been using Active Directory and we're not sure how much complexity this is going to add to our administration. Is there a discernible difference/benefit to going one way or the other?
Then, when we sign up our developers we can either have everyone sign up with their live ID's (we have MSDN w/ VS Premium credits for all developers) or we can set them up using Active Directory with Work Accounts. Having our credits allotted in work accounts sounds like a good way to control things at first reading, but it also seems a bit more complex. I'm wondering if there is much difference between MSDN accounts signed up w/ live IDs or AD Work Accounts. I can't find a real comparison article or pro/con type of discussion anywhere.
It sounds like you have already figured out the main differences. As an organization, I would suggest signing up for Azure as an organization. You can do that here. This is going to give you the management capabilities for resources typically needed by an organization.
Your developers can continue to use the MSDN subscriptions. As Dylan commented, these are not to be used for production environments. You should consider using these for Dev/Test environments and activating your MSDN benefits. This will save you some money. More on that here.
Visual Studio Online will work with your Work Accounts and again give you more control over managing your online resources. This link describes the sign-up process for both Microsoft Accounts and Work Accounts. And if you scroll down a bit you will find your original question specifically addressed.
Finally, you can also add your Work Account(s) to your existing MSDN subscriptions if you like. This way you (and your developers) can use the same account credentials when accessing Azure Subscriptions. Information on how to do that is available in this link.
Your Work Account subscription should be limited to personnel responsible for managing your "production" environment.
After signing up for Azure as an Organization, you can add users to the directory as described here. You can also add "external" users using their existing Microsoft Accounts. It's just a few dialogs to add a user.