À propos des migrations à partir de Azure DevOps Cloud
Vous pouvez utiliser GitHub Enterprise Importer pour migrer des référentiels de Azure DevOps vers GitHub Enterprise Cloud (GitHub.com ou GHE.com).
Vous pouvez uniquement utiliser GitHub Enterprise Importer pour migrer à partir de Azure DevOps Cloud, et non à partir de Azure DevOps Server. Si vous utilisez actuellement Azure DevOps Server et que vous souhaitez migrer vers GitHub, vous pouvez d’abord migrer vers Azure DevOps Cloud. Pour plus d’informations, consultez Migrate vers Azure DevOps sur le site Azure.
Avant de créer votre compte d’entreprise sur GitHub, déterminez si votre entreprise utilisera Enterprise Managed Users. Cela affecte la façon dont vos membres s’authentifient et gèrent les identités et l’accès. Consultez « Choix d’un type d’entreprise pour GitHub Enterprise Cloud ».
Pour en savoir plus sur les différences entre GitHub et Azure DevOps, consultez Différences clés entre Azure DevOps et GitHub.
Prise en charge des Azure Pipelines et des Azure Boards
Les Azure Pipelines et les Azure Boards peuvent être entièrement intégrés à votre expérience GitHub. Vous pouvez configurer votre compte d’entreprise et Azure DevOps afin de pouvoir continuer à utiliser ces services tout en bénéficiant de l’hébergement de vos référentiels sur GitHub.
Si vous souhaitez migrer Azure Pipelines vers GitHub Actions, contactez votre responsable de compte GitHub.
Données migrées
GitHub Enterprise Importer prend actuellement en charge la migration des données de référentiel suivantes de Azure DevOps vers GitHub Enterprise Cloud.
- Source Git (y compris l’historique des commits)
- Requêtes de tirage
- Historique utilisateur pour les requêtes de tirage
- Liens d’élément de travail sur les pull requests
- 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)
Limitations relatives aux données migrées
Il existe des limites à ce que GitHub Enterprise Importer peut migrer. Certains sont dus à des limitations de GitHub, tandis que d’autres sont des limitations de GitHub Enterprise Importer lui-même.
Limitations de GitHub
- Limite de taille de 2 Gio pour une validation Git unique : Aucune validation unique dans votre référentiel Git ne peut être supérieure à 2 Gio. Si l’une de vos validations est supérieure à 2 Gio, vous devez fractionner la validation en validations plus petites qui sont chacune de 2 Gio ou plus petites.
- Limite de 255 octets pour les références Git : Aucune référence Git unique, communément appelée « ref », ne peut avoir un nom supérieur à 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 que les caractères non ASCII, tels que les emojis, peuvent consommer plusieurs octets. Si l’une de vos références Git est trop grande, nous retournons un message d’erreur clair.
- Limite de taille de fichier MiB 100 : Une fois votre migration terminée, aucun fichier unique dans votre référentiel Git ne peut être supérieur à 100 Mio. Pendant la migration du référentiel, cette limite est augmentée à 400 Mio. Envisagez d’utiliser Git LFS pour stocker des fichiers volumineux.
Limitations de GitHub Enterprise Importer
- Limite de taille de 40 Go pour un référentiel Git (préversion publique) : 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 taille de fichier de 400 Mio : Lors de la migration d’un référentiel avec GitHub Enterprise Importer, aucun fichier unique de votre référentiel Git ne peut dépasser 400 Mio. Envisagez d’utiliser Git LFS pour stocker des fichiers volumineux.
Git LFS objets non migrés :**Importer peut migrer des 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.
- 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. - Le contenu des utilisateurs fictifs pourrait ne pas être accessible à la recherche : les utilisateurs fictifs sont des utilisateurs d’espace réservé auxquels le contenu importé (tel que les problèmes, les pull requests, 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.