Prise en main d’Azure DevOps Data Migration Tool
Avant d’utiliser l’outil de migration de données Azure DevOps pour migrer votre base de données avec une haute fidélité, découvrez quelques-uns des concepts de base de cet article.
Découvrir les données migrées
Toutes les données ne sont pas migrées. Les bases de données distinctes en dehors de la collection, par exemple les données de création de rapports et SharePoint, ne sont pas migrées. Les sections suivantes répertorient plus de détails sur les données qui sont migrées.
Données incluses
Le tableau suivant présente les données incluses dans la migration.
| Données incluses | Description |
|---|---|
| Mappage de collection | Chaque collection dans Azure DevOps Server correspond à une base de données. Pendant la migration, l’ensemble de la collection, y compris les éléments de travail, l’historique, les ensembles de modifications TFVC (Team Foundation Version Control), les données Git, les définitions de build et bien plus encore, sont migrés vers Azure DevOps Services. L’élément de travail, l’ensemble de modifications TFVC et les numéros de validation Git restent inchangés. |
Données exclues
Le tableau suivant présente des exclusions de données spécifiques dans la migration.
| Données exclues | Description |
|---|---|
| Extensions | Les extensions doivent être réinstallées après la migration. Vous devez publier des extensions locales sur la Place de marché en tant qu’extensions privées et partagées avec le compte. |
| Crochets de services | Les données service Hooks ne sont pas incluses dans la migration ; reconfigurer après la migration. |
| Test de charge | Les données de test de charge ne sont pas introduites ; reconfigurez les tests de charge après la migration. |
| Agents de pipeline et pools d’agents | Reconfigurez les agents de pipeline et les pools d’agents après la migration. |
| Mentions | Les mentions utilisateur dans les discussions sur les éléments de travail conservent l’identité locale, et non le nouvel ID Microsoft Entra. Le pointage sur les noms d’utilisateur n’affiche pas les cartes de visite, et certains liens hypertexte peuvent ne pas être valides. |
| Intégrations de Project Server | Non disponible pour Azure DevOps Services. Par exemple, builds XAML, Gestionnaire de tests Microsoft, SharePoint, SQL Data Warehouse, et ainsi de suite. |
| Fonctionnalités de préversion | Certaines fonctionnalités d’Azure DevOps Server peuvent être préversions lors de la migration vers Azure DevOps Services. |
Limites de projet
Si votre collection contient de nombreux projets, Azure DevOps Services impose une limite de 1 000 projets par organisation, bien que nous recommandons 300 ou moins. Au-delà de ce seuil, certaines expériences, telles que la connexion à l’organisation à partir de Visual Studio, peuvent se dégrader. Pour rester dans la limite, envisagez de fractionner la collection ou de supprimer des projets plus anciens.
Comprendre la relation entre les bases de données locales et les organisations Azure DevOps.
Avant de vous plonger trop profondément dans la planification de votre migration, il est important de comprendre au niveau élevé comment fonctionne le processus de migration de base de données. Les migrations fonctionnent sur les concepts principaux suivants :
- Collection de projets d’équipe : les collections dans Azure DevOps Server sont un conteneur physique pour les projets d’équipe et leurs artefacts. Chaque collection équivaut à une base de données SQL unique et est la source des migrations vers Azure DevOps Services.
- Organisation Azure DevOps Services : les organisations sont l’unité de gestion du service hébergé dans le cloud. Logiquement, ils mappent 1:1 au concept d’une collection de projets d’équipe dans Azure DevOps Server. Par conséquent, les organisations sont la destination des migrations vers Azure DevOps Services. Par exemple, les organisations Azure DevOps Services sont représentées comme
https://dev.azure.com/Contosooù Contoso représente le nom de l’organisation Azure DevOps Services.
Lorsque vous migrez une base de données SQL de collection de projets d’équipe, l’outil de migration de données crée une organisation Azure DevOps avec un nom fourni par l’utilisateur. La migration d’une base de données de collecte vers une organisation Azure DevOps Services existante ou la consolidation de plusieurs bases de données de regroupement dans une seule organisation Azure DevOps Services n’est pas possible. Le mappage est strictement un-à-un entre les collections de projets d’équipe et les organisations Azure DevOps Services.
Choisir un centre de données
Lorsque vous configurez votre organisation Azure DevOps Services, vous pouvez choisir l’emplacement de vos données. Lors de la création initiale de l’inscription et de l’organisation, sélectionnez une région qui répond à vos besoins. Pour utiliser ultérieurement pour la migration, notez le code abrégé de la région. Pour plus d’informations, consultez régions prises en charge pour la migration.
Comprendre les tarifs
Une question qui est généralement fournie avec la migration est le type de licence dont une entreprise a besoin pour utiliser Azure DevOps Services. La bonne nouvelle est que vous êtes susceptible d’avoir toutes les licences dont vous avez déjà besoin. Nous avons créé un exemple de feuille de calcul qui doit couvrir la plupart des cas. Si vous avez des questions spécifiques sur votre situation, contactez votre spécialiste des ventes de solutions pour développeurs ou revendeur Microsoft. Pour plus d’informations, consultez Tarification pour Azure DevOps.
Feuille de calcul des licences utilisateur
| # | Colonne 1 | Colonne 2 |
|---|---|---|
| 1 | Nombre de membres de l’équipe | |
| 2 | Nombre de parties prenantes | |
| 3 | Soustraire la valeur de la ligne 2 de la valeur de la ligne 1* | |
| 4 | Nombre d’abonnés Visual Studio** | |
| 5 | Soustraire la valeur de la ligne 4 de la valeur de la ligne 3 | |
| 6 | Soustraire la valeur de la ligne 5 de la valeur de la ligne 5*** |
- *Les parties prenantes sont gratuites
- ** Les abonnés Visual Studio ont inclus Azure DevOps Services comme avantage de l’abonnement
- Chaque organisation Azure DevOps Services obtient cinq utilisateurs gratuits
Pour plus d’informations sur les options rentables d’accès aux fonctionnalités, consultez la vue d’ensemble de la facturation et la calculatrice de prix Azure.
Achetez les licences utilisateur Azure DevOps Services nécessaires via visual Studio Marketplace ou la Portail Azure. Nous allons examiner ce processus pendant la phase de préparation de l’exécution de test.
En plus des fonctionnalités principales, les services à valeur ajoutée suivants sont disponibles dans Azure DevOps que vous pouvez trouver avantageux :
- Services de test de charge hébergés : si vous devez simuler et analyser les performances de vos applications sous charge, Azure DevOps fournit des services de test de charge hébergés. Ces services vous permettent de tester vos applications et d’identifier les goulots d’étranglement ou les problèmes de performances.
- Extensions de Gestionnaire de tests : pour une gestion complète des tests, envisagez d’utiliser des extensions Test Manager. Ces extensions améliorent vos fonctionnalités de test en fournissant des fonctionnalités telles que la gestion des cas de test, les tests exploratoires et le suivi d’exécution des tests.
- Plus de fonctionnalités : Azure DevOps propose différentes extensions et intégrations qui répondent à des besoins spécifiques. Qu’il s’agisse d’intégrer des outils non-Microsoft, d’améliorer la sécurité ou d’automatiser des pipelines de déploiement, il existe un large éventail d’options.
Certains de ces services peuvent être fournis avec des coûts supplémentaires, il est donc essentiel d’évaluer vos besoins et votre budget en conséquence. Ces coûts apparaissent sur votre facture sous l’abonnement associé. Pour plus d’informations, consultez Configurer la facturation. Si vous avez des questions spécifiques sur votre situation, contactez votre partenaire DevOps, votre revendeur Microsoft ou votre spécialiste des ventes microsoft Developer Solutions pour obtenir des conseils personnalisés.
Réserver votre nouvelle organisation
Compte tenu de la chronologie du projet de migration, nous vous recommandons de réserver le nom de votre organisation dès le début pour vous assurer que le nom souhaité est disponible pour votre migration finale.
Par exemple, si votre entreprise est Contoso et que vous souhaitez une organisation avec un nom correspondant, par exemple, https://dev.azure.com/contosovous pouvez créer une organisation avec ce nom maintenant. Mais gardez à l’esprit que vous pouvez uniquement migrer vers une organisation Azure DevOps Services toute nouvelle.
Procédez comme suit pour réserver le nom de votre organisation.
- Réservation initiale :
- Créez une organisation avec un nom temporaire, par exemple
https://dev.azure.com/contoso-temporary. - Réservez ce nom temporaire pour votre migration ultérieure.
- Créez une organisation avec un nom temporaire, par exemple
- Migration finale :
- Lorsque vous êtes prêt à commencer la migration finale, effectuez-la dans l’organisation
https://dev.azure.com/contoso-temporary. - Une fois la migration réussie, renommez l’organisation réservée pour ouvrir le nom souhaité pour l’organisation importée. Renommez-le plutôt que de le supprimer, car une suppression peut prendre jusqu’à une heure pour libérer le nom, lors du renommage immédiat.
- Renommez immédiatement l’organisation migrée en nom de désir, par exemple,
https://dev.azure.com/contosoque vous venez de supprimer en renommant. - Si vous le souhaitez, vous pouvez supprimer l’organisation réservée et renommée à l’origine à ce stade.
- Lorsque vous êtes prêt à commencer la migration finale, effectuez-la dans l’organisation
En suivant cette approche, vous avez une transition fluide tout en garantissant que votre nom d’organisation préféré reste disponible.