Si vous êtes membre d’une organisation qui a migré d’Azure DevOps vers GitHub, ce guide explique les modifications apportées à vos flux de travail pour que la migration soit aussi fluide que possible.
Structure
Dans Azure DevOps, les référentiels sont imbriqués à l’intérieur de projets d’équipe, de sorte que la structure de votre environnement ressemble à ceci :
- Organisation
- Projet d'équipe
- Référentiels
- Projet d'équipe
- Référentiels
- Projet d'équipe
Flux d’autorisations et de visibilité à partir du projet d’équipe.
GitHub est structuré différemment. Les dépôts sont imbriqués directement à l’intérieur des organisations, qui contiennent également des équipes :
- Compte d’entreprise
- Organisation
- Équipes
- Référentiels
- Organisation
- Équipes
- Référentiels
- Organisation
Les autorisations et la visibilité sont déterminées par une combinaison d’appartenances à l’organisation, d’appartenance à l’équipe et d’autorisations individuelles.
Le concept d’un projet d’équipe, utilisé pour regrouper des dépôts dans Azure DevOps, n’existe pas dans GitHub et le traitement des organisations dans GitHub comme l’équivalent des projets d’équipe n’est pas recommandé.
Bien que vous puissiez initialement constater que chaque organisation migrée sur GitHub dispose d'une longue liste désorganisée de dépôts, vous pouvez accorder l'accès et les autorisations via des équipes de membres de l'organisation, ce qui facilite grandement la navigation dans les dépôts de l'organisation.
Authentification, autorisations et équipes
Il existe deux méthodes pour l’authentification auprès de GitHub. La méthode que vous utilisez dépend de la façon dont le compte d’entreprise est configuré.
Si votre compte d'entreprise utilise Enterprise Managed Users, vous vous connecterez à GitHub via votre fournisseur d'identité (par exemple, Entra ID) et utiliserez un compte provisionné lié au compte d'entreprise.
Sinon, vous allez utiliser un compte personnel GitHub. Ce compte sera invité au compte d’entreprise et toutes les organisations dans lesquelles vous travaillerez. Si le compte d’entreprise est configuré avec des restrictions d’accès supplémentaires via SAML, votre compte personnel est lié à votre fournisseur d’identité. Vous serez invité à vous authentifier auprès de l'IdP lorsque vous aurez besoin d'accéder aux ressources dans le compte d’entreprise.
Dans une entreprise sur GitHub, les référentiels peuvent être publics, privés ou internes. Les dépôts privés sont uniquement visibles par les personnes et les équipes disposant d’un accès explicite, et les référentiels internes sont visibles par tous les membres de votre entreprise, mais pas pour les personnes extérieures à l’entreprise. Les dépôts internes sont utiles lorsque plusieurs organisations de la même entreprise doivent découvrir et réutiliser du code. Si votre entreprise utilise Enterprise Managed Users, les comptes d’utilisateur ne peuvent pas créer de référentiels publics ou d’autres contenus publics.
Utilisation de Git
Pour continuer à travailler sur vos dépôts à l’aide de Git, vous devez apporter des modifications.
- Mettez à jour les URL distantes pour qu’elles pointent sur GitHub. Consultez Création de dépôt distants.
- Mettez à jour la façon dont vous vous authentifiez.
- Pour utiliser l’authentification HTTPS, vous devez créer un personal access token. Consultez Gestion de vos jetons d’accès personnels.
- Pour utiliser l’authentification SSH, vous devez créer ou ajouter une clé SSH existante à GitHub. Consultez Connexion à GitHub à l’aide de SSH.
- Si votre entreprise ou organisation utilise l’authentification unique SAML, vous devez autoriser votre personal access token ou la clé SSH avant de pouvoir accéder aux ressources.
Flux de demande de tirage
Avec votre base de code maintenant hébergée sur GitHub, vous proposerez des modifications à l'aide de pull requests créées dans vos référentiels GitHub.
Si votre entreprise a intégré Azure Boards et Pipelines, ces deux fonctions fonctionnent avec GitHub. Vous pouvez continuer à référencer des éléments de travail dans vos messages de commit et pull requests. Par exemple : Fix login bug (AB#1234).
Vous pouvez continuer à afficher et gérer vos éléments de travail sur Azure Boards. Vous pouvez également lier des branches, des validations et des pull requests à des éléments de travail depuis Azure. Consultez comment associer les validations GitHub, les requêtes de tirage, les branches et les problèmes aux éléments de travail dans Azure Boards sur Microsoft Learn.
Protections de branche
Les personnes disposant d’un accès administrateur à un référentiel peuvent configurer des règles de protection de branche sur GitHub. Ces stratégies sont similaires aux stratégies de branche sur Azure DevOps et définissent des règles telles qu’un nombre minimal d’approbation des réviseurs, des vérifications d’état réussies et l’exigence de validations signées.
GitHub prend également en charge l’attribution automatique de réviseurs en fonction du fichier, du dossier et des modèles glob dans le fichier CODEOWNERS d’un référentiel. Consultez À propos des propriétaires de code.
Packages et artefacts
Dans Azure DevOps, vous avez peut-être utilisé Azure Artifacts pour publier et consommer des packages (par exemple, des packages NuGet, des packages npm ou des packages Maven) et stocker des artefacts de build générés par Azure Pipelines.
Sur GitHub, les packages sont généralement publiés sur GitHub Packages et associés à un référentiel ou une organisation. Selon la façon dont votre entreprise a effectué la migration, vous pouvez continuer à publier des packages sur Azure Artifacts, déplacer des packages vers GitHub Packages, ou utiliser une combinaison des deux.
Si vous ne pouvez plus restaurer les dépendances après la migration, vérifiez la configuration de votre source de package. Par exemple, vous devrez peut-être mettre à jour une URL de Registre ou des informations d’identification dans des fichiers tels que nuget.config, .npmrc, settings.xmlou dans votre configuration de pipeline.
Pour plus d’informations, consultez « Introduction aux packages GitHub ».
GitHub Copilot
L’hébergement de vos référentiels sur GitHub libère tout le potentiel de Copilot. Votre base de code fournit Copilot avec tout le contexte nécessaire pour répondre aux questions dans Discussion avec Copilot, examiner et formuler des suggestions dans vos pull requests, et même effectuer des modifications en votre nom avec Agent de programmation Copilot.
Consultez Démarrage rapide pour GitHub Copilot.