Types de migrations
Vous pouvez effectuer trois types de migrations :
- Une migration d’une instance de GitHub Enterprise Server vers une autre instance GitHub Enterprise Server existante. Vous pouvez migrer n’importe quel nombre de dépôts appartenant à un utilisateur ou une organisation sur l’instance. Avant d’effectuer une migration, vous devez disposer d’un accès administrateur de site aux deux instances.
- Une migration d’une organisation GitHub.com vers une instance de GitHub Enterprise Server. Vous pouvez migrer n’importe quel nombre de dépôts appartenant à l’organisation. Avant d’effectuer une migration, vous devez disposer d’un accès administratif à l’organisation GitHub.com et d’un accès administrateur de site à l’instance cible.
- Les essais sont des migrations qui importent des données dans une instance de préproduction. Ils vous permettent de voir ce qui se passerait si une migration était appliquée à GitHub.com. Nous vous recommandons vivement d’effectuer un essai sur une instance intermédiaire avant d’importer des données dans votre instance de préproduction.
Note
L’utilisation de ghe-migrator n’est pas recommandée pour transférer une instance GitHub Enterprise Server d’un hyperviseur à un autre. Nous vous suggérons plutôt de sauvegarder et de restaurer dans le nouvel emplacement avec GitHub Enterprise Server Backup Utilities, ou de créer un réplica dans le nouvel emplacement, puis de basculer vers l’appliance réplica. Pour plus d’informations, consultez « Configuration des sauvegardes sur votre instance », « Création d’un réplica à haute disponibilité » et « Lancement d’un basculement vers votre appliance réplica ».
Données migrées
ghe-migrator est centré sur un référentiel. La plupart des données associées à un dépôt peuvent être migrées. Par exemple, un dépôt dans une organisation migre le dépôt et l’organisation ainsi que tous les utilisateurs, équipes, problèmes et demandes de tirage (pull request) associés au dépôt.
Les éléments du tableau ci-dessous peuvent être migrés avec un dépôt. Les éléments qui ne figurent pas dans la liste des données migrées ne peuvent pas être migrés, notamment les ressources Git LFS.
Remarque : les relations de duplication ne persistent pas après une migration.
| Données associées à un dépôt migré | Notes |
|---|---|
| Utilisateurs | Les @mentions d’utilisateurs sont réécrites pour correspondre à la cible. |
| Organisations | Le nom et les détails d’une organisation sont migrés. |
| Référentiels | Les liens vers les arborescences, blobs, commits et lignes Git sont réécrits pour correspondre à la cible. Les référentiels internes sont migrés en tant que dépôts privés. L’état de l’archive n’est pas défini. |
| Wikis | Toutes les données wiki sont migrées. |
| Teams | Les @mentions d’équipes sont réécrites pour correspondre à la cible. |
| Étapes majeures | Les horodatages sont conservés. |
| Panneaux Projects (classic) | Projets (classique) associés au dépôt et à l'organisation qui possède le dépôt sont migrés. Projects, la toute nouvelle expérience de projet, n'est pas pris en charge. |
| Problèmes | Les références de problème et les horodatages sont conservés. |
| Commentaires de problème | Les références croisées aux commentaires sont réécrites pour l’instance cible. |
| Demandes de tirage | Les références croisées aux demandes de tirage sont réécrites pour correspondre à la cible. Les horodatages sont conservés. |
| Revues de demande de tirage | Les revues de demande de tirage et les données associées sont migrées. |
| Commentaires de revues de demande de tirage | Les références croisées aux commentaires sont réécrites pour l’instance cible. Les horodatages sont conservés. Les commentaires au niveau du fichier ne sont pas migrés. |
| Commentaires de commit | Les références croisées aux commentaires sont réécrites pour l’instance cible. Les horodatages sont conservés. |
| Versions | Toutes les données de versions sont migrées. |
| Actions effectuées sur les demandes de tirage ou les problèmes | Toutes les modifications apportées aux demandes de tirage ou aux problèmes, notamment l’attribution d’utilisateurs, le renommage des titres et la modification d’étiquettes, sont conservées ainsi que les horodatages pour chaque action. |
| Pièces jointes | Les fichiers joints aux problèmes et demandes de tirage sont migrés. Vous pouvez désactiver la migration de ces éléments. |
| Webhooks | Seuls les webhooks actifs sont migrés. |
| Clés de déploiement de dépôt | Les clés de déploiement de dépôt sont migrées. |
| Branches protégées | Les paramètres de branche protégée et les données associées sont migrés. |
À propos de la migration des données d’authentification externes
Si l’emplacement source de votre migration est un produit GitHub qui utilise l’authentification LDAP ou SAML, ghe-migrator ne migre pas les données d’authentification externe liées aux comptes d’utilisateur. Pour plus d’informations sur les options d’authentification, consultez GitHub Enterprise Server, et consultez « À propos de l’authentification pour votre entreprise » dans les documents GitHub Enterprise Server » ou les documents GitHub Enterprise Cloud.
S vous migrez vers une instance de destination, puis configurez l’authentification externe, les utilisateurs doivent se connecter à l’instance de destination avec un compte d’utilisateur ayant le même nom d’utilisateur ou le même identifiant utilisateur que le compte sur l’instance source. Les administrateurs peuvent passer en revue l’attribut externe qu’une instance utilise pour mapper les noms de comptes d’utilisateur à partir de données Management Console. Pour plus d’informations, consultez « Accès à la console de gestion ».