Si vous êtes membre d'une organisation qui a migré de 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 dans des projets team, 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
Les autorisations et la visibilité héritent 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 de projets d’équipe n’est pas recommandé.
Bien qu'il s'avère qu'il y a initialement une longue liste non organisée de référentiels pour chaque organisation migrée sur GitHub, vous pouvez accorder l'accès et les autorisations par l'intermédiaire des équipes composées des membres de l'organisation, ce qui facilite considérablement la navigation dans les référentiels de l'organisation.
Authentification, autorisations et équipes
Il existe deux méthodes d’authentification à 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 allez vous connecter à GitHub via votre fournisseur d'identité (par exemple, Entra ID) et utiliser un compte provisionné lié au compte d'entreprise.
Sinon, vous utiliserez un compte personnelGitHub . 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 dépôts 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 vers GitHub. Consultez Gestion de dépôts 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 avec SSH.
- Si votre entreprise ou organisation utilise l’authentification unique SAML, vous devez autoriser votre clé SSH ou votre personal access token clé SSH pour pouvoir accéder aux ressources.
Flux de demande de tirage
Avec votre base de code maintenant hébergée sur GitHub, vous allez proposer des modifications à l’aide de requêtes de tirage 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 à partir d'Azure. Consultez Associer des commits GitHub, demandes de tirage, branches et 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 politiques de branche sur Azure DevOps et définissent des règles telles qu'un nombre minimal de réviseurs approuvant, la réussite des vérifications d'état et la nécessité de validations signées.
GitHub prend également en charge l’attribution automatique de réviseurs en fonction des fichiers, des dossiers et des modèles globaux dans le fichier CODEOWNERS d’un référentiel. Consultez [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners).
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 pour stocker des artefacts de build générés par Azure Pipelines.
Les packages sont généralement publiés sur GitHub et associés à un référentiel ou à une organisation représentée par GitHub Packages. 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 déverrouille toute la puissance de Copilot. Votre codebase fournit Copilot le contexte dont il a besoin pour répondre aux questions, Copilot Chat examiner et faire des suggestions dans vos pull requests, et même effectuer des modifications en votre nom. agent Copilot de cloud
Consultez Démarrage rapide pour GitHub Copilot.