Skip to main content
Nous publions des mises à jour fréquentes de notre documentation, et la traduction de cette page peut encore être en cours. Pour obtenir les informations les plus actuelles, consultez la documentation anglaise.
All products
Migrations

Migration de référentiels d’Azure DevOps vers GitHub Enterprise Cloud

Dans cet article

Vous pouvez migrer des référentiels d’Azure DevOps vers GitHub Enterprise Cloud, en utilisant GitHub CLI ou l’API GraphQL.

Remarque : GitHub Enterprise Importer est actuellement en version bêta publique et peut faire l’objet de modifications.

À propos des migrations de dépôts avec GitHub Enterprise Importer

Vous pouvez exécuter votre migration avec GitHub CLI ou l’API.

GitHub CLI simplifie le processus de migration et est recommandé pour la plupart des clients. Les clients avancés avec de grands besoins de personnalisation peuvent utiliser l’API pour créer leurs propres intégrations avec GitHub Enterprise Importer.

Pour voir les instructions d’utilisation de l’API, utilisez le sélecteur d’outils en haut de la page.
To see instructions for using the GitHub CLI, use the tool switcher at the top of the page.

Prérequis

  • Pour veiller à bien comprendre les limitations connues du support de l’importateur, consultez « À propos de GitHub Enterprise Importer ».
  • Nous vous recommandons vivement d’effectuer une exécution d’essai de votre migration et d’effectuer votre migration de production peu après. Pour en savoir plus sur les bonnes pratiques relatives aux exécutions d’essai, consultez « Préparation à l’exécution d’une migration avec GitHub Enterprise Importer ».
  • Bien que cela ne soit pas obligatoire, nous vous recommandons d’interrompre votre travail pendant votre migration de production. Importer ne prend pas en charge les migrations delta, donc aucune modification apportée pendant la migration ne sera migrée. Si vous choisissez de ne pas interrompre le travail pendant votre migration de production, vous devrez migrer manuellement ces modifications.
  • Pour l’organisation de destination sur GitHub.com, vous devez être propriétaire d'une organisation ou avoir le rôle de migrateur. Pour plus d’informations, consultez « Octroi du rôle de migrateur pour GitHub Enterprise Importer ».

Étape 0 : Se préparer pour utiliser l’API GraphQL GitHub

To make GraphQL queries, you'll need to write your own scripts or use an HTTP client like Insomnia.

To learn more about getting started with the GitHub GraphQL API, including how to authenticate, see "Formation d’appels avec GraphQL."

Étape 1 : Obtenir le ownerId de la destination de votre migration

En tant que propriétaire de l’organisation dans GitHub Enterprise Cloud, utilisez la requête GetOrgInfo pour retourner l’ownerId, également appelé ID d’organisation, pour l’organisation dont vous souhaitez posséder les dépôts migrés. Vous aurez besoin de l’ownerId pour identifier votre destination de migration.

Requête GetOrgInfo

query(
  $login: String!
){
  organization (login: $login)
  {
    login
    id
    name
    databaseId
  }
}
Variable de requêteDescription
loginNom de votre organisation.

Réponse GetOrgInfo

{
  "data": {
    "organization": {
      "login": "Octo",
      "id": "MDEyOk9yZ2FuaXphdGlvbjU2MTA=",
      "name": "Octo-org",
      "databaseId": 5610
    }
  }
}

Dans cet exemple, MDEyOk9yZ2FuaXphdGlvbjU2MTA= est l’ID d’organisation ou le ownerId, que nous utiliserons à l’étape suivante.

Étape 2 : Identifier à partir d’où vous effectuez la migration

Vous pouvez configurer une source de migration à l’aide de la requête createMigrationSource. Vous devez fournir l’ownerId, ou l’ID d’organisation, collecté à partir de la requête GetOrgInfo.

Votre source de migration est votre organisation ADO.

Mutation de createMigrationSource

mutation createMigrationSource($name: String!, $ownerId: ID!) {
  createMigrationSource(input: {name: $name, url: "https://dev.azure.com", ownerId: $ownerId, type: AZURE_DEVOPS}) {
    migrationSource {
      id
      name
      url
      type
    }
  }
}

Remarque : Veillez à utiliser AZURE_DEVOPS pour type.

Variable de requêteDescription
nameNom pour votre source de migration. Ce nom est juste pour vous, donc vous pouvez utiliser n’importe quelle chaîne.
ownerIdID d’organisation de votre organisation sur GitHub Enterprise Cloud.

Réponse de createMigrationSource

{
  "data": {
    "createMigrationSource": {
      "migrationSource": {
        "id": "MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA",
        "name": "Azure Devops Source",
        "url": "https://dev.azure.com",
        "type": "AZURE_DEVOPS"
      }
    }
  }
}

Dans cet exemple, MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA est l’ID de la source de la migration, que nous allons utiliser à l’étape suivante.

Étape 3 : Démarrer la migration de votre dépôt

Lorsque vous démarrez une migration, un seul dépôt et ses données associées migrent vers un tout nouveau dépôt GitHub que vous identifiez.

Si vous souhaitez déplacer plusieurs dépôts à la fois de la même organisation source, vous pouvez mettre en file d’attente plusieurs migrations. Vous pouvez exécuter jusqu’à 5 migrations de dépôt en même temps.

Mutation de startRepositoryMigration

mutation startRepositoryMigration (
  $sourceId: ID!,
  $ownerId: ID!,
  $sourceRepositoryUrl: URI!,
  $repositoryName: String!,
  $continueOnError: Boolean!,
  $accessToken: String!,
  $githubPat: String!,
  $targetRepoVisibility: String!
){
  startRepositoryMigration( input: {
    sourceId: $sourceId,
    ownerId: $ownerId,
    repositoryName: $repositoryName,
    continueOnError: $continueOnError,
    accessToken: $accessToken,
    githubPat: $githubPat,
    targetRepoVisibility: $targetRepoVisibility
    sourceRepositoryUrl: $sourceRepositoryUrl,
  }) {
    repositoryMigration {
      id
      migrationSource {
        id
        name
        type
      }
      sourceUrl
    }
  }
}
Variable de requêteDescription
sourceIdid de votre source de migration retournée par la mutation createMigrationSource.
ownerIdID d’organisation de votre organisation sur GitHub Enterprise Cloud.
repositoryNameNom de dépôt unique personnalisé qui n’est actuellement utilisé par aucun de vos dépôts appartenant à l’organisation sur GitHub Enterprise Cloud. Un problème de journalisation des erreurs sera créé dans ce dépôt une fois votre migration terminée ou arrêtée.
continueOnErrorParamètre de migration qui permet à la migration de se poursuivre en cas d’erreurs qui n’entraînent pas l’échec de la migration. Doit être true ou false. Nous vous recommandons vivement de définir continueOnError sur true afin que votre migration continue, sauf si Importer ne peut pas déplacer la source Git ou que Importer a perdu la connexion et ne peut pas se reconnecter pour terminer la migration.
githubPatpersonal access token pour votre organisation de destination sur GitHub Enterprise Cloud. Pour connaître les exigences en termes de personal access token, consultez « Gestion de l’accès pour GitHub Enterprise Importer ».
accessTokenpersonal access token pour votre source.
targetRepoVisibilityVisibilité du nouveau dépôt. Doit être private, public ou internal. Si elle n’est pas définie, votre dépôt est migré avec une visibilité privée.

À l’étape suivante, vous allez utiliser l’ID de migration retourné par la mutation startRepositoryMigration pour vérifier l’état de la migration.

Étape 4 : Vérifier l’état de votre migration

To detect any migration failures and ensure your migration is working, you can check your migration status using the getMigration query. You can also check the status of multiple migrations with getMigrations.

The getMigration query will return with a status to let you know if the migration is queued, in progress, failed, or completed. If your migration failed, the Importer will provide a reason for the failure.

getMigration query

query (
  $id: ID!
){
  node( id: $id ) {
    ... on Migration {
      id
      sourceUrl
      migrationSource {
        name
      }
      state
      failureReason
    }
  }
}
Query variableDescription
idThe id of your migration that the startRepositoryMigration mutation returned.

Étape 5 : Valider votre migration et consulter le journal des erreurs

Pour terminer votre migration, nous vous recommandons de consulter le problème « Journal de migration ». Ce problème est créé sur GitHub dans le dépôt de destination.

Capture d’écran d’un problème avec le titre « Journal de migration ». Le deuxième commentaire du problème contient les journaux d’une migration.

Enfin, nous vous recommandons de passer en revue vos dépôts migrés pour en contrôler l’intégrité.

Étape 1 : installer ADO2GH extension of the GitHub CLI

S’il s’agit de votre première migration, vous devez installer ADO2GH extension of the GitHub CLI. Pour plus d’informations sur GitHub CLI, consultez « À propos de GitHub CLI ».

  1. Installez GitHub CLI. Pour obtenir des instructions d’installation pour GitHub CLI, consultez le dépôt GitHub CLI.

    Remarque : Vous devez avoir la version 2.4.0 ou ultérieure de GitHub CLI. Vous pouvez vérifier la version que vous avez installée avec la commande gh --version.

  2. Installez ADO2GH extension.

    Shell
    gh extension install github/gh-ado2gh

Dès que vous avez besoin d’aide sur ADO2GH extension, vous pouvez utiliser l’indicateur --help avec une commande. Par exemple, gh ado2gh --help liste toutes les commandes disponibles et gh ado2gh migrate-repo --help liste toutes les options disponibles pour la commande migrate-repo.

Étape 2 : mettre à jour ADO2GH extension of the GitHub CLI

ADO2GH extension of the GitHub CLI est mis à jour toutes les semaines. To make sure you're using the latest version, update the extension.

Shell
gh extension upgrade github/gh-ado2gh

Étape 3 : Définir les variables d’environnement

Avant de pouvoir utiliser ADO2GH extension pour migrer vers GitHub Enterprise Cloud, vous devez créer des personal access token qui peuvent accéder aux organisations source et de destination, puis définir les personal access token en tant que variables d’environnement.

  1. Créez et enregistrez un personal access token qui servira d’authentification pour l’organisation de destination sur GitHub Enterprise Cloud, en vous assurant qu’il répond à toutes les exigences. Pour plus d’informations, consultez « Gestion de l’accès pour GitHub Enterprise Importer ».

  2. Créez et enregistrez un personal access token qui servira d’authentification pour l’organisation source, en vous assurant qu’il répond également aux mêmes exigences.

  3. Définissez les variables d’environnement pour les personal access token, en remplaçant TOKEN dans les commandes ci-dessous par les personal access token que vous avez enregistrés ci-dessus. Utilisez GH_PAT pour l’organisation de destination et ADO_PAT pour l’organisation source.

    • Si vous utilisez le Terminal, utilisez la commande export.

      Shell
      export GH_PAT="TOKEN"
export ADO_PAT="TOKEN"

    • Si vous utilisez PowerShell, utilisez la commande $env.

      Shell
      $env:GH_PAT="TOKEN"
$env:ADO_PAT="TOKEN"

Étape 4 : Générer un script de migration

Si vous souhaitez migrer simultanément plusieurs dépôts vers GitHub Enterprise Cloud, utilisez GitHub CLI pour générer un script de migration. Le script résultant contiendra une liste de commandes de migration, une par dépôt.

Remarque : La génération d’un script génère un script PowerShell. Si vous utilisez le Terminal, vous devez générer le script avec l’extension de fichier .ps1 et installer PowerShell pour Mac ou Linux pour l’exécuter.

Si vous souhaitez migrer un seul dépôt, passez à l’étape suivante.

Génération d’un script de migration

Pour générer un script de migration, exécutez la commande gh ado2gh generate-script.

Shell
gh ado2gh generate-script --ado-org SOURCE --github-org DESTINATION --output FILENAME

Pour ajouter des fonctionnalités supplémentaires au script, telles que le recâblage des pipelines, la création d'équipes et la configuration d’intégrations Azure Boards, vous pouvez ajouter l’indicateur --all.

Si vous souhaitez que le script télécharge le journal de migration pour chaque dépôt migré, ajoutez l’indicateur --download-migration-logs. Pour plus d’informations sur les journaux de migration, consultez « Accès à vos journaux de migration pour GitHub Enterprise Importer ».

Remplacez les espaces réservés dans la commande ci-dessus par les valeurs suivantes.

Espace réservé | Valeur | ----------- | ----- | SOURCE | Nom de l’organisation source DESTINATION | Nom de l’organisation de destination FILENAME | Nom de fichier du script de migration résultant

Si vous utilisez le Terminal, choisissez une extension de fichier .ps1, car le script généré exige l’exécution de PowerShell. Vous pouvez installer PowerShell pour Mac ou Linux.

Examen du script de migration

Après avoir généré le script, passez en revue le fichier et, éventuellement, modifiez le script.

  • S’il y a des dépôts que vous ne souhaitez pas migrer, supprimez ou commentez les lignes correspondantes.
  • Si vous souhaitez que les dépôts aient un nom différent dans l’organisation de destination, mettez à jour la valeur de l’indicateur --target-repo correspondant.

Remarque : Si votre dépôt contient plus de 10 Go de données de mise en production, les mises en production ne peuvent pas être migrées. Utilisez l’indicateur --skip-releases pour migrer le dépôt sans les mises en production.

Étape 5 : Migrer des dépôts

Vous pouvez migrer plusieurs dépôts à l’aide d’un script de migration ou un seul dépôt avec la commande gh ado2gh migrate-repo.

Migrer plusieurs dépôts

Pour migrer plusieurs dépôts, exécutez le script que vous avez généré ci-dessus. Remplacez FILENAME dans les commandes ci-dessous par le nom de fichier que vous avez fourni lors de la génération du script.

  • Si vous employez le Terminal, utilisez ./.
    Shell
    ./FILENAME
  • Si vous employez PowerShell, utilisez .\.
    Shell
    .\FILENAME

Migrer un seul dépôt

Pour migrer un seul dépôt, utilisez la commande gh ado2gh migrate-repo.

Shell
gh ado2gh migrate-repo --ado-org SOURCE --ado-team-project TEAM-PROJECT --ado-repo CURRENT-NAME --github-org DESTINATION --github-repo NEW-NAME

Remplacez les espaces réservés dans la commande ci-dessus par les valeurs suivantes.

Espace réservé | Valeur | ----------- | ----- | SOURCE | Nom de l’organisation source CURRENT-NAME | The name of the repository you want to migrate DESTINATION | Nom de l’organisation de destination NEW-NAME | Nom que vous souhaitez donner au dépôt migré

Étape 6 : Valider votre migration et consulter le journal des erreurs

When your migration is complete, we recommend reviewing your migration log. For more information, see "Accès à vos journaux de migration pour GitHub Enterprise Importer."

We recommend that you review your migrated repositories for a soundness check.