Cette version de GitHub Enterprise Server n'est plus disponible depuis le 2024-09-25. Aucune publication de correctifs n’est effectuée, même pour les problèmes de sécurité critiques. Pour de meilleures performances, une sécurité améliorée et de nouvelles fonctionnalités, effectuez une mise à niveau vers la dernière version de GitHub Enterprise. Pour obtenir de l’aide sur la mise à niveau, contactez le support GitHub Enterprise.

Informations sur les migrations d’Azure DevOps vers GitHub Enterprise Cloud

Découvrez les données que GitHub Enterprise Importer peut migrer.

Dans cet article

À propos des migrations à partir d’Azure DevOps

Vous pouvez utiliser GitHub Enterprise Importer pour migrer des référentiels d’Azure DevOps vers GitHub Enterprise Cloud.

Vous pouvez uniquement utiliser GitHub Enterprise Importer pour migrer à partir d’Azure DevOps Cloud, et non à partir d’Azure DevOps Server. Si vous utilisez actuellement Azure DevOps Server et souhaitez effectuer une migration vers GitHub, vous pouvez d’abord le faire vers Azure DevOps Cloud. Pour plus d’informations, consultez Migrez vers Azure DevOps sur le site Azure.

Données migrées

Actuellement, nous prenons uniquement en charge la migration des données de dépôt suivantes depuis Azure DevOps vers GitHub Enterprise Cloud.

  • Source Git (y compris l’historique des commits)
  • Demandes de tirage
  • Historique utilisateur pour les demandes de tirage
  • Liens d’élément de travail sur les demandes de tirage
  • Pièces jointes sur les demandes de tirage
  • Les stratégies de branche pour le référentiel (les stratégies de branche définies pour l'utilisateur et les stratégies de branche entre référentiels ne sont pas incluses)

Si vous souhaitez migrer Azure Pipelines vers GitHub Actions, contactez votre responsable de compte GitHub.

Limitations relatives aux données migrées

Il existe des limites à ce que GitHub Enterprise Importer peut migrer. Certaines sont dues à des limitations de GitHub, tandis que d’autres sont des limitations de GitHub Enterprise Importer lui-même.

Limitations de GitHub

  • Taille limite de 2 Go pour un commit Git : Aucun commit de votre dépôt Git ne peut dépasser 2 Go. Si l’un de vos commits dépasse 2 Go, vous devez le diviser en commits plus petits de 2 Go chacun ou moins.
  • Limite de 255 octets pour les références Git : Aucune référence Git, communément appelée « ref », ne peut avoir un nom qui dépasse 255 octets. En règle générale, cela signifie que vos références ne peuvent pas contenir plus de 255 caractères, mais tous les caractères non-ASCII, tels que les emojis, peuvent consommer plus d’un octet. Si l’une de vos références Git est trop grande, nous retournons un message d’erreur clair.
  • Taille limite de fichier de 100 Mo : Aucun fichier dans votre dépôt Git ne peut dépasser 100 Mo. Envisagez d’utiliser Git LFS pour stocker des gros fichiers. Pour plus d’informations, consultez « Gestion des fichiers volumineux ».

Limitations de GitHub Enterprise Importer

  • Taille limite de 10 Go pour un dépôt Git : Cette limite s’applique uniquement au code source. Pour vérifier si l’archive du référentiel dépasse la limite, utilisez l’outil git-sizer et passez en revue la taille totale de l’objet blob dans la sortie. L’outil git-sizer permet également d’identifier les problèmes potentiels liés aux fichiers volumineux, à la taille d’objet blob, à la taille de validation et aux nombres d’arborescences susceptibles d’avoir un impact sur les migrations.
  • Limite de 10 Go pour les métadonnées : Importer ne peut pas migrer les dépôts qui ont plus de 10 Go de métadonnées. Les métadonnées comprennent les problèmes, les demandes de tirage, les mises en production et les pièces jointes. Dans la plupart des cas, les métadonnées volumineuses sont dues aux ressources binaires attachées aux mises en production. Vous pouvez exclure des mises en production de la migration avec l’indicateur --skip-releases de la commande migrate-repo, puis déplacer vos mises en production manuellement après la migration.
  • Objets Git LFS non migrés : Importer peut migrer les dépôts qui utilisent Git LFS, mais les objets LFS eux-mêmes ne seront pas migrés. Ils peuvent être poussés vers votre destination de migration en tant que tâche de suivi une fois la migration terminée. Pour plus d’informations, consultez « Duplication d’un dépôt ».
  • Tâches de suivi requises : Lors de la migration entre produits GitHub, certains paramètres ne sont pas migrés et doivent être reconfigurés dans le nouveau dépôt. Pour obtenir la liste des tâches de suivi que vous devrez effectuer après chaque migration, consultez « Vue d’ensemble d’une migration entre produits GitHub ».
  • Fonctionnalité de recherche de code différée : La réindexation de l’index de recherche peut prendre quelques heures après la migration d’un dépôt, et les recherches de code peuvent retourner des résultats inattendus tant que la réindexation n’est pas terminée.
  • Les ensembles de règles configurés pour votre organisation peuvent entraîner l’échec des migrations : Par exemple, si vous avez configuré une règle qui exige que les adresses e-mail des auteurs de commit se terminent par @monalisa.cat, et que le dépôt que vous migrez contient des commits qui ne sont pas conformes à cette règle, votre migration échoue. Pour plus d’informations sur les ensembles de règles, consultez « À propos des ensembles de règles ».
  • Le contenu de mannequin ne peut pas être recherchable : les mannequins sont des utilisateurs d’espace réservé auxquels le contenu importé (tels que les problèmes, les demandes de tirage, les commentaires, etc.) est associé. Lorsque vous recherchez du contenu associé à un mannequin, tel que des problèmes attribués, ces problèmes peuvent ne pas être trouvés. Une fois qu’un mannequin est récupéré, le contenu doit être trouvé via le nouveau propriétaire. Pour plus d’informations, consultez « Récupération de mannequins pour GitHub Enterprise Importer ».

Mise en route

Avant de migrer à partir d’Azure DevOps, vous devez planifier la façon dont vous allez exécuter votre migration. Avant de migrer des données, vous devez choisir quelqu’un pour exécuter la migration. Vous devez accorder à cette personne l’accès nécessaire pour la source et la destination de la migration. Nous vous recommandons également d’exécuter une migration d’évaluation gratuite en premier.

Pour obtenir une vue d’ensemble du processus de migration du début à la fin, consultez « Vue d’ensemble d’une migration d’Azure DevOps vers GitHub Enterprise Cloud ».