À propos des migrations entre les entreprises résidentes de données
Les migrations entre deux entreprises résidentes de données utilisent le flux de migration d’archive GEI standard :
- GEI se connecte au sous-domaine source GHE.com .
- GEI génère une archive contenant les données du référentiel.
- GEI charge l’archive dans le stockage de migration pris en charge.
- GEI démarre la migration du référentiel sur le sous-domaine de destination GHE.com .
- La destination Importer télécharge et traite l’archive.
Dans cette migration :
- La source est un GHE.com sous-domaine, tel que
https://SOURCE_SUBDOMAIN.ghe.com. - La destination est un sous-domaine différent GHE.com , tel que
https://DESTINATION_SUBDOMAIN.ghe.com. - Les organisations sources et de destination peuvent avoir des noms différents.
- Le dépôt migré peut avoir un nom différent dans l’organisation de destination.
Les points de terminaison de l’API source et de destination doivent être spécifiés indépendamment. N’utilisez pas l’URL de l’API de destination pour les opérations sources.
Important
GitHub Enterprise Cloud avec résidence des données Les URL d’API utilisent le format https://api.SUBDOMAIN.ghe.com. Ceci est différent d’une GitHub Enterprise Server URL d’API, qui utilise généralement le format https://HOSTNAME/api/v3.
Prerequisites
Avant de commencer :
- Vérifiez que la source et la destination sont des sous-domaines différents GHE.com .
- Dans l’organisation source comme dans l’organisation de destination, assurez-vous d’être propriétaire de l’organisation ou de vous être vu attribuer le rôle de migrateur.
- Créez un personal access token (classic) pour l’organisation source.
- Créez personal access token (classic) pour l’organisation de destination. Pour connaître les étendues requises, consultez Gestion de l’accès pour une migration entre des produits GitHub.
- Exécutez une migration d’évaluation avant d’effectuer la migration de production.
Nous vous recommandons d’arrêter temporairement le travail sur le référentiel source pendant la migration de production. GitHub Enterprise Importer n’effectue pas de migrations delta, de sorte que les modifications apportées après le démarrage de la migration ne sont pas incluses automatiquement.
Pour plus d’informations sur les données migrées et les limitations connues, consultez À propos des migrations entre les produits GitHub avec GitHub Enterprise Importer.
Installer le GitHub CLI et GEI
Installez GitHub CLI, puis installez l’extension GEI :
gh extension install github/gh-gei
gh extension install github/gh-gei
Mettez à jour l’extension avant de démarrer une migration :
gh extension upgrade github/gh-gei
gh extension upgrade github/gh-gei
Pour afficher les options disponibles :
gh gei migrate-repo --help
gh gei migrate-repo --help
Définir des variables d’environnement
Définissez les personal access tokens pour les deux entreprises :
export GH_SOURCE_PAT="SOURCE_PERSONAL_ACCESS_TOKEN" export GH_PAT="DESTINATION_PERSONAL_ACCESS_TOKEN"
export GH_SOURCE_PAT="SOURCE_PERSONAL_ACCESS_TOKEN"
export GH_PAT="DESTINATION_PERSONAL_ACCESS_TOKEN"
Définissez l’URL de l’API pour chaque GHE.com sous-domaine :
export SOURCE_API_URL="https://api.SOURCE_SUBDOMAIN.ghe.com" export TARGET_API_URL="https://api.DESTINATION_SUBDOMAIN.ghe.com"
export SOURCE_API_URL="https://api.SOURCE_SUBDOMAIN.ghe.com"
export TARGET_API_URL="https://api.DESTINATION_SUBDOMAIN.ghe.com"
Remplacez DESTINATION_SUBDOMAIN et SOURCE_SUBDOMAIN par les sous-domaines de votre entreprise source et de destination.
Par exemple:
export SOURCE_API_URL="https://api.source-example.ghe.com" export TARGET_API_URL="https://api.destination-example.ghe.com"
export SOURCE_API_URL="https://api.source-example.ghe.com"
export TARGET_API_URL="https://api.destination-example.ghe.com"
Le GH_SOURCE_PAT jeton est utilisé pour les opérations côté source, notamment la génération d’archive. Le GH_PAT jeton est utilisé pour les opérations côté destination.
Configurer le stockage Blob d’archive
GitHub Enterprise Importer exporte chaque projet dans une archive, puis téléverse l’archive vers le stockage Blob que GitHub peut lire. Vous choisissez le back-end de stockage lorsque vous exécutez une migration :
| Option de stockage | Comment le sélectionner | Remarques |
|---|
GitHub-owned blob storage (recommandé) | --use-github-storage | Aucune configuration n’est requise.
GitHub supprime automatiquement l’archive après une migration réussie, ou sept jours après une migration ayant échoué.
AWS S3 |
--aws-bucket-name (avec les variables d’environnement AWS_REGION, AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY, et éventuellement AWS_SESSION_TOKEN) | Vous êtes propriétaire du bucket et de son cycle de vie.
GitHub ne supprime pas les archives de votre stockage.
Service de stockage Blob Azure |
AZURE_STORAGE_CONNECTION_STRING variable d’environnement (pour une seule migrate-repo commande, vous pouvez utiliser --azure-storage-connection-stringà la place) | Seules les chaînes de connexion utilisant la clé d’accès du compte de stockage sont prises en charge (pas les SAS).
GitHub ne supprime pas les archives de votre stockage.
Migrer un seul dépôt
Pour migrer un référentiel unique, utilisez la gh gei migrate-repo commande :
gh gei migrate-repo \ --github-source-org SOURCE_ORGANIZATION \ --source-repo SOURCE_REPOSITORY \ --github-source-api-url "$SOURCE_API_URL" \ --github-target-org DESTINATION_ORGANIZATION \ --target-repo DESTINATION_REPOSITORY \ --target-api-url "$TARGET_API_URL" \ --verbose
gh gei migrate-repo \
--github-source-org SOURCE_ORGANIZATION \
--source-repo SOURCE_REPOSITORY \
--github-source-api-url "$SOURCE_API_URL" \
--github-target-org DESTINATION_ORGANIZATION \
--target-repo DESTINATION_REPOSITORY \
--target-api-url "$TARGET_API_URL" \
--verbose
Remplacez les espaces réservés par les valeurs suivantes :
| Texte de remplacement | Description |
|---|---|
SOURCE_ORGANIZATION | Organisation propriétaire du référentiel dans l’entreprise source. |
SOURCE_REPOSITORY | Nom du référentiel dans l’organisation source. |
DESTINATION_ORGANIZATION | Organisation propriétaire du référentiel migré dans l’entreprise de destination. |
DESTINATION_REPOSITORY | Nom du nouveau référentiel dans l’organisation de destination. |
Par exemple:
gh gei migrate-repo \ --github-source-org source-org \ --source-repo example-repository \ --github-source-api-url "$SOURCE_API_URL" \ --github-target-org destination-org \ --target-repo example-repository \ --target-api-url "$TARGET_API_URL" \ --verbose
gh gei migrate-repo \
--github-source-org source-org \
--source-repo example-repository \
--github-source-api-url "$SOURCE_API_URL" \
--github-target-org destination-org \
--target-repo example-repository \
--target-api-url "$TARGET_API_URL" \
--verbose
Si vous omettez --target-repo, GEI utilise le nom du référentiel source.
Arguments facultatifs
Vous pouvez ajouter les options suivantes à la commande de migration :
| Argument | Description |
|---|---|
--target-repo-visibility TARGET-VISIBILITY | Définit la visibilité du nouveau référentiel. Les valeurs prises en charge sont private et internal. |
--skip-releases | Migre le référentiel sans mise en production. |
--queue-only | Met en file d’attente la migration sans attendre qu’elle se termine. |
--verbose | Affiche des résultats supplémentaires de la migration. |
Par exemple:
gh gei migrate-repo \ --github-source-org source-org \ --source-repo example-repository \ --github-source-api-url "$SOURCE_API_URL" \ --github-target-org destination-org \ --target-repo example-repository \ --target-api-url "$TARGET_API_URL" \ --target-repo-visibility internal \ --verbose
gh gei migrate-repo \
--github-source-org source-org \
--source-repo example-repository \
--github-source-api-url "$SOURCE_API_URL" \
--github-target-org destination-org \
--target-repo example-repository \
--target-api-url "$TARGET_API_URL" \
--target-repo-visibility internal \
--verbose
Migrer plusieurs dépôts
Pour plusieurs référentiels, utilisez gh gei generate-script.
gh gei generate-script \ --github-source-org SOURCE_ORGANIZATION \ --github-target-org DESTINATION_ORGANIZATION \ --github-source-api-url "$SOURCE_API_URL" \ --target-api-url "$TARGET_API_URL" \ --output migration-script.ps1
gh gei generate-script \
--github-source-org SOURCE_ORGANIZATION \
--github-target-org DESTINATION_ORGANIZATION \
--github-source-api-url "$SOURCE_API_URL" \
--target-api-url "$TARGET_API_URL" \
--output migration-script.ps1
Passez en revue le script généré avant de l’exécuter. Vous pouvez:
- Supprimez les référentiels qui ne doivent pas être migrés.
- Modifiez les noms des référentiels de destination.
- Modifier la visibilité du référentiel de destination.
- Ajoutez des options telles que
--skip-releases. - Ajoutez
--download-migration-logsafin de pouvoir télécharger les journaux de chaque migration.
Exécutez le script généré avec PowerShell :
pwsh ./migration-script.ps1
pwsh ./migration-script.ps1
Vérifier l’état d’une migration
Si vous avez démarré la migration avec --queue-only, utilisez l’ID de migration imprimé par GEI pour le surveiller :
gh gei wait-for-migration \ --migration-id MIGRATION_ID \ --target-api-url "$TARGET_API_URL" \ --verbose
gh gei wait-for-migration \
--migration-id MIGRATION_ID \
--target-api-url "$TARGET_API_URL" \
--verbose
Remplacez MIGRATION_ID par l’ID retourné par gh gei migrate-repo.
Remarque
Incluez les deux arguments d’URL d’API lors de la vérification. L’URL de l’API source est requise pour les commandes GEI qui récupèrent les informations et journaux de migration côté source.
Télécharger les journaux de migration
Pour télécharger les journaux de migration :
gh gei download-logs \ --migration-id MIGRATION_ID \ --github-source-api-url "$SOURCE_API_URL" \ --target-api-url "$TARGET_API_URL"
gh gei download-logs \
--migration-id MIGRATION_ID \
--github-source-api-url "$SOURCE_API_URL" \
--target-api-url "$TARGET_API_URL"
Passez en revue les journaux pour détecter les avertissements et les erreurs, même lorsque la migration indique qu’elle a réussi.
Abandonner une migration
Pour abandonner une migration en file d’attente ou en cours d’exécution :
gh gei abort-migration \ --migration-id MIGRATION_ID \ --github-source-api-url "$SOURCE_API_URL" \ --target-api-url "$TARGET_API_URL"
gh gei abort-migration \
--migration-id MIGRATION_ID \
--github-source-api-url "$SOURCE_API_URL" \
--target-api-url "$TARGET_API_URL"
Troubleshooting
Impossible d’atteindre le locataire source
Vérifiez que :
--github-source-api-urlest défini sur le sous-domaine source.- L’URL utilise le format
https://api.SUBDOMAIN.ghe.com. - Le jeton source est stocké dans
GH_SOURCE_PAT. - Le jeton a accès à l’organisation et au référentiel source.
Impossible d’atteindre le locataire de destination
Vérifiez que :
--target-api-urlest défini sur le sous-domaine de destination.- L’URL utilise le format
https://api.SUBDOMAIN.ghe.com. - Le jeton de destination est stocké dans
GH_PAT. - Vous êtes autorisé à créer des référentiels dans l’organisation de destination.
La migration échoue lors de la génération ou du chargement de l’archive
Passez en revue la sortie et les journaux de migration, puis vérifiez que :
- Le stockage d’archivage de migration est configuré correctement.
- Le fournisseur de stockage est accessible au service de migration.
- Le référentiel source n’est pas modifié pendant la migration.
- Les URL de l’API source et de destination n’ont pas été échangées.
Les journaux ne peuvent pas être téléchargés
Lorsque vous utilisez download-logs, wait-for-migrationou abort-migration, fournissez les mêmes URL d’API source et de destination que celles utilisées pour démarrer la migration :
--github-source-api-url "$SOURCE_API_URL" \
--target-api-url "$TARGET_API_URL"
L’URL source est rejetée
Veillez à utiliser le point de terminaison d’API du sous-domaine GHE.com plutôt qu’un point de terminaison GitHub Enterprise Server.
Utilisez :
https://api.SUBDOMAIN.ghe.com
N’utilisez pas :
https://HOSTNAME/api/v3
Le /api/v3 format est destiné aux GitHub Enterprise Server sources et n’est pas le format correct pour GitHub Enterprise Cloud avec résidence des données.