Migration transparente de Bitbucket vers GitHub: un guide étape par étape et des principaux plats – partie 2

Dans le première partie De cette série de blogs, nous avons traversé notre décision de migrer de Bitbucket à Github, la planification stratégique qui y est allée et comment nous avons jeté les bases d’une transition réussie. De l’alignement des parties prenantes à la construction de scripts d’automatisation personnalisés, chaque étape a été conçue pour soutenir une migration à grande échelle.

Dans Partie 2nous nous concentrerons sur l’exécution du monde réel – couvrant le Défis auxquels nous avons été confrontés, les résultats obtenus, et le apprentissages clés et meilleures pratiques Cela est sorti du déploiement de plus de 1 600 référentiels avec une perturbation minimale.

Défis pendant la migration

1. Plugin GitHub Org: La gestion de la création d’emplois et de l’organisation de Jenkins pour plusieurs référentiels dans différentes organisations GitHub pendant la migration des bibliothèques Jenkins était complexe.
   Solution: Le plugin GitHub Organisation a été utilisé pour automatiser la numérisation des organisations GitHub, créer des travaux Jenkins pour chaque référentiel et les organiser en dossiers nommés d’après les organisations. Tous les travaux Jenkins nouvellement migrés ont utilisé la configuration directement à partir de leurs référentiels GitHub respectifs, en maintenant la cohérence et le contrôle des versions dans la structure du dossier de l’organisation GitHub.
2. Bibliothèque partagée: L’un des principaux défis était de gérer deux versions d’une bibliothèque partagée. Le premier était la bibliothèque existante qui était basée sur la structure Bitbucket. Cette bibliothèque a été implicitement chargée dans le cadre de la configuration de Jenkins. Le second contenait les modifications qui lui ont permis d’exécuter à l’aide des référentiels sur GitHub. Jenkins ne peut pas charger deux bibliothèques implicitement avec les deux ayant la même définition de fonction.
   Solution: Nous avons déplacé la première version de la configuration de la bibliothèque Jenkins vers le dossier du projet Bitbucket sur Jenkins. Cela nous a permis de charger l’implicitement pour les projets Bitbucket uniquement plutôt que les Jenkins mondiaux. De même, nous avons configuré le deuxième Verison de la bibliothèque partagée sur le dossier GitHub-Org avec la charge implicite.
3. PR fermé: Les demandes de traction fermées n’ont pas pu être migrées car les branches source et cible n’existent pas ou ne sont actuellement pas dans l’État lors de la création de PR.
   Solution: Pour y remédier, une branche distincte a été créée avec des détails sur les relations publiques fermées historiques avec des détails de conversation pour les stocker pour référence future.
4. Gestion des référentiels avec des noms similaires: Lors de la génération du fichier repos.csv (utilisé comme entrée pour les scripts de migration), il a été découvert que Bitbucket a permis des référentiels avec la même limace sous différentes clés de projet. Cependant, GitHub ne prend pas en charge les référentiels avec des limaces en double, conduisant à des conflits potentiels pendant la migration.
   Solution: Pour résoudre ce problème, un ensemble de scripts utilitaires a été créé:
   1. preCheck_github.sh: vérifié l’existence de chaque référentiel sur github répertorié dans Repos.csv, empêchant les erreurs de duplication.
   2. répéter_value.sh: identifié les noms de référentiel en double dans RepOS.csv, aidant les projets BitBucket isolat avec les mêmes limaces.
   3. current_inventory.sh: généré une liste détaillée de l’inventaire Bitbucket actuel avec des filtres (par exemple, archivé True / False) pour suivre l’état de la migration des référentiels.
5. Cas de bord: Au cours du processus de migration, certains référentiels avaient des caractéristiques uniques ou des structures spécifiques à la langue (par exemple, des référentiels de langage GO ou des projets basés sur Terraform). Ceux-ci nécessitaient une manipulation spéciale et n’ont pas pu suivre le flux de migration standard.
   Solution: Des scripts personnalisés ont été développés pour gérer ces cas de bord:
   1. go_exclude.sh: Des référentiels GO filtrés en excluant ceux qui ont un fichier go.mod ou tout fichier GO, garantissant que seuls les référentiels non go ont été inclus dans l’inventaire standard.
   2. project_wise_repository.sh: Généré une liste de référentiels Bitbucket basés sur des conventions de dénomination spécifiques ou des clés de projet, permettant un contrôle plus granulaire sur la segmentation des stocks
6. LFS (stockage de fichiers grand):Chez Bitbucket: de nombreux référentiels de Bitbucket n’ont pas réussi à clone de Bitbucket car les objets LFS ont été désactivés du référentiel en raison duquel le processus de clonage n’a pas pu être terminé.
   Solution: Activer Autoriser LFS dans les paramètres du référentiel GitHub.
7. Gérer différents cas de Git LFS, c’est-à-dire
   1. La différence de limite de taille des fichiers pour Bitbucket (4 Go) et GitHub (100 Mo).
   2. Le fichier référencé en tant qu’objet LFS n’a pas pu être poussé pour être github.
   3. Git LFS n’a pas pu suivre le répertoire de travail actuel.
   4. Git LFS Version Mismatch
   
   Solution: Faites une version clone nue du référentiel et importez tous les fichiers avec GIT LFS, y compris le nom d’extension du fichier.
8. Référentiels fourchis: Quelques référentiels étaient des fourches d’autres référentiels, par exemple les gomodules et les scripts TF. Cela a provoqué les problèmes ci-dessous tandis que les migrations sont liées aux spécifications du chemin et aux références de demande de traction cachée
   ! [remote rejected] erreurs après refléter un référentiel Git
   Solution : Exclure les références du référentiel pendant le clonage ou avoir un clone nu du référentiel Cela vous permettra de pousser / miroir sans .Git Configs.
9. .gitignore: Fichiers restreints dans .gitignore IE; .txt .json dans certains des référentiels et les référentiels ont également été limités dans les fichiers .gitignore qui ne nous ont pas permis de pousser avec les limaces et les extensions mentionnées ci-dessus lors de la poussée des informations liées aux informations.
   Solution: Modifiez l’extension en .pr et retirez la limace de réapprovisionnement de la branche PR fermée.
10. Référentiel vide: La présence de référentiels vides abrupte le flux de script comme d’autres processus comme la migration des relations publiques, etc. n’ont pas pu être effectués sur un référentiel vide.Solution: Créé un inventaire distinct pour le référentiel vide et mis à jour le script pour le traiter.
11. Limitation du système d’exploitation: En utilisant Bash, nous avons utilisé la commande SED pour les remplacements qui ont été effectués dans le fichier en fonction de la migration effectuée. Les tests locaux ont été réussis mais la commande SED varie en fonction de l’utilisation du système d’exploitation.
    Solution: SED a donc été remplacé par AWK afin qu’il puisse être utilisé sur n’importe quel serveur.
12. URL de référence: Les URL sous-modules ont été modifiées en fonction des adresses GIT pour les référentiels migrés, mais lors des tests, il a été constaté que le JenkinsFile n’a pas pu trouver certains fichiers dépendants car le GIT n’était pas synchronisé avec le sous-module.
    Solution: Mise à jour du script avec la commande git sync et testé les builds.
13. Webhooks: Pendant la migration Webhook, les référentiels Bitbucket avaient des URL Webhook privées / authentifiées qui ont déclenché un script interne qui a géré l’exécution de l’emploi Jenkins.
    Solution: Cette solution n’a pas pu être utilisée avec GitHub en raison de laquelle une seule URL basée sur l’organisation (plugin GitHub) a été créée pour répondre aux exigences.
14. Versioning: Les référentiels migrés avaient des bibliothèques Jenkins obsolètes et des balises GIT basées sur le nombre de build qui n’étaient plus pertinentes.
    Solution: Les scripts Groovy dans les bibliothèques de Jenkins ont été mis à jour et toutes les balises existantes ont été supprimées pour réinitialiser le versement proprement.

Résultat de la migration:

Migration réussie de référentiels de Bitbucket à GitHub avec des autorisations appropriées, Règles de protection des succursales, mises à jour du sous-module, modifications de Jenkinsfile, Configurations Webhooket un état archivé pour les référentiels. Un rapport post-migration vérifie l’exactitude de la configuration.

Apprentissages clés

1. La planification pré-migration est essentielle
   1. Définissez clairement la stratégie de migration, indiquant les structures du référentiel, les autorisations et les intégrations.
   2. Communiquez le plan de migration vers toutes les parties prenantes à l’avance.
2. Vérification des données
   1. Assurez-vous que tous les référentiels, y compris les succursales, les étiquettes et les antécédents, sont correctement migrés.
   2. Vérifiez qu’il n’y a pas de perte de données en effectuant des contrôles d’intégrité.
   3. Vérifiez les structures et autorisations du référentiel conformément à la configuration d’origine.
   4. Assurez-vous que tous les webhooks migrés sont corrects et en bon état de fonctionnement.
3. Gestion de l’accès et des autorisations
   1. Le modèle d’autorisation dans GitHub est différent de celui de Bitbucket; Un bon réglage de l’accès à l’équipe est important.
4. Gestion des intégrations CI / CD et gestion des webhooks et intégrations tierces
   1. Identifiez les différences entre Bitbucket → Jenkins et GitHub → Jenkins Connection ou tout outils CI / CD.
   2. Mettez à jour les configurations et les secrets pour assurer un déploiement en douceur après la migration.
   3. Les webhooks et les intégrations (par exemple, Jira, Slack, Ci-CD outils) peuvent avoir besoin d’être reconfigurés après la migration.
   4. Vérifiez les limites de taux de l’API et les mécanismes d’authentification pour éviter les perturbations du service
5. Résolution du problème lié au référentiel
   1. Les grands référentiels peuvent nécessiter une optimisation avant la migration (par exemple, l’élagage des histoires inutiles).
   2. Identifier et résoudre les problèmes de dépendance liés aux LF ou sous-modules GIT.
6. Validation et tests post-migration:
   1. Vérifiez que toutes les branches, balises et engagements sont là.
   2. Exécutez les déploiements de test et les workflows pour valider la configuration dans GitHub.

Temps de migration de base

temps de migration

Autres statistiques clés

statistiques clés

Avantages réalisés:

1. Entretien et mises à niveau Bitbucket
2. Économie des coûts des serveurs et licences Bitbucket
3. Contrôle de version robuste, CI / CD et intégrations AI

Réflexions finales

1. Toute migration, quelle que soit la taille, peut devenir simple avec la bonne planification et les bons devoirs.
2. La plupart des problèmes semblent intimidants au départ, mais ils ne sont souvent pas aussi complexes qu’ils le paraissent une fois approché méthodiquement.
3. Les scripts appropriés, l’identification proactive des problèmes et la résolution collaborative sont essentielles pour l’exécution transparente.

Cette expérience a été un exercice d’apprentissage rigoureux, affiner nos processus et adopter les meilleures pratiques pour les migrations de référentiel à grande échelle.