Fermer

avril 16, 2021

Migration de code GitHub à l'aide de l'automatisation DevOps


La migration d'un système de gestion de code à un autre est un exercice non trivial. La plupart du temps, l'équipe souhaite conserver l'historique du code, la structure de la branche, les autorisations de l'équipe et les intégrations. Ce billet de blog examine une telle migration de Bitbucket vers GitHub pour une grande organisation de maintenance de la santé.

En raison de sa croissance et de ses acquisitions au fil du temps, l'organisation a constaté que les équipes de développement utilisaient plusieurs systèmes de contrôle de source. Cela a entraîné une augmentation des dépenses en raison des efforts de soutien et des coûts de licence en double. Cela incluait la gestion de la plate-forme, l'intégration automatisée de l'intégration continue / livraison continue (CI / CD) et l'assistance aux utilisateurs finaux. Pour résoudre ces problèmes, GitHub a été choisi comme plate-forme unique pour le contrôle de code source. Le produit d'entreprise GitHub offre de nombreux avantages, notamment des intégrations d'outils (par exemple, des web-hooks, un accès basé sur une clé SSH, des plugins de workflow), une interface utilisateur intuitive pour la gestion d'équipe et de projet, et des notifications sur des événements spécifiques liés au comportement (par exemple, pull-request, fusion, création de branche). De plus, il existe la possibilité de déployer dans le cloud ou sur site leur plate-forme de gestion du code source (SCM).

La migration de plusieurs milliers de référentiels a présenté un défi de taille. Au-delà de la logistique de la coordination, il était également nécessaire que l'équipe DevOps respecte le délai serré autour du renouvellement de la licence. Pour éviter cette dépense supplémentaire, les équipes ont dû migrer non seulement la base de code, mais toutes les méta-données associées (par exemple, l'historique des succursales, les autorisations des utilisateurs, les intégrations d'outils, etc.). Dans l'approche détaillée ci-dessous, nous avons largement exploité les flux de travail CloudBees Jenkins ™, les playbooks Red Hat Ansible ™ et les scripts Python ™ pour effectuer une grande partie du travail de configuration et de migration requis.

Approche

Comme le montre la figure 1, l'effort de migration impliquait la création d'un flux de travail de migration Jenkins basé sur les informations fournies par l'utilisateur pour définir le projet source Bitbucket, le projet cible GitHub, les informations de propriété de l'équipe, les informations de référentiel et les exigences d'intégration supplémentaires. Ces informations de migration ont été stockées dans un nouveau fichier ajouté à la racine de l'arborescence source ("app-info.yml"). Cette approche facilite l'intégration future de l'automatisation et fournit un moyen simple de suivre les métadonnées d'application dans la base de code elle-même.

 Github Migration Automation Map (3)

Figure 1. Flux de travail d'automatisation de la migration GitHub

Il y avait plusieurs considérations à prendre en compte dans l'automatisation de la migration GitHub, notamment s'assurer que le projet GitHub cible disposait des autorisations de visibilité appropriées (par exemple, public / private), en utilisant des normes de dénomination de projet cohérentes, en s'intégrant à l'automatisation de l'analyse de sécurité préexistante ou à établir, en appliquant les règles de protection des succursales définies par l'organisation et en maintenant toute l'automatisation du pipeline CI / CD nécessaire.

Code Transfer

Bien que techniquement l'opération de migration la plus simple consistait à cloner le code dans le nouveau référentiel, ce qui nécessitait des modifications manuelles importantes de plusieurs fichiers d'automatisation clés conservés à la racine de la structure des dossiers du projet. Par exemple, la configuration Jenkins préexistante («Jenkinsfile») a été mise à jour après la migration pour pointer vers le bon projet de bibliothèque partagée; ceux-ci avaient été précédemment migrés vers GitHub depuis Bitbucket. Malheureusement, étant donné que chaque équipe de développement utilisait une version de bibliothèque spécifique, cette étape était une activité d’intégration manuelle plutôt qu’automatisée. Par exemple, la politique exige qu’une pull-request soit approuvée par au moins un réviseur avant la fusion de code pour les branches «master», «release» et «develop» au sein du référentiel. Ces règles ont été encodées dans les scripts Python de migration et extraites du playbook Ansible lors de la création du projet GitHub.

Modifications automatisées du pipeline CI / CD

Pour prendre en charge les pipelines CI / CD existants, les bases de code migrées ont nécessité un pipeline mises à jour du fichier de configuration. Cela comprenait des liens de configuration pour les mises à jour automatisées des problèmes Jira, une exécution correcte du maître / agent Jenkins (c'est-à-dire des web-hooks), des analyses d'automatisation de la sécurité et une intégration avec le contrôle des packages de bibliothèque (par exemple, JFrog Artifactory ™). Ces modifications ont été capturées dans les scripts de migration Python et extraites du playbook Ansible lors de la migration du code GitHub.

Gestion des clés d'accès et des comptes de service

Les processus CI / CD automatisés nécessitent souvent l'utilisation de comptes de service et de clés d'accès secrètes partagées pour fonctionner correctement. Au cours de la migration de GitHub, il était extrêmement important de conserver ces clés d'accès pour éviter une exposition inappropriée aux journaux, aux notifications ou à tout autre rapport non sécurisé. L'équipe de migration GitHub a utilisé la fonctionnalité de coffre-fort Ansible et les scripts Groovy pour mettre à jour la gestion des informations d'identification Jenkins intégrée afin de garantir que les secrets / comptes / clés spécifiques au projet étaient transférés en toute sécurité vers les tâches liées GitHub nouvellement créées pendant le processus de migration.

GitHub Pre -Migration Setup

L'intégration de GitHub Jenkins a été construite comme une tâche distincte pour créer «l'équipe» GitHub. Cela incluait la configuration de l'équipe avec un nom correct, des utilisateurs d'administration et une correspondance dans le dossier de construction Jenkins. Pour chaque référentiel, nous avons également défini un «web-hook» Jenkins pour garantir que le maître Jenkins approprié est utilisé pour exécuter chaque pipeline CI / CD.

Automated Testing Integration

Dans le cadre du contrôle de la qualité du code, l'analyse de code SonarQube est lié à un référentiel défini et requis dans le cadre du flux de travail Jenkins CI / CD. Les résultats de l'analyse sont rapportés dans un onglet GitHub distinct qui devait être mis en correspondance avec l'équipe du projet. De cette manière, le projet GitHub nouvellement créé pouvait rapporter directement aux développeurs les résultats de l'analyse automatisée de la qualité du code.

Résultats

L'équipe de mise en service DevOps devait respecter un délai très serré de quatre mois pour terminer la migration complète. de Bitbucket à GitHub et évitez les frais de renouvellement de licence. Compte tenu de l'ampleur du défi, la seule solution viable était d'automatiser autant que possible la migration. Lorsqu'une intervention manuelle était nécessaire, l'équipe DevOps a clairement communiqué une liste de contrôle des activités aux équipes concernées pour les changements avant et après la migration. À l'aide de l'ensemble d'outils combiné de tâches Jenkins scriptées, de playbooks Ansible et de scripts Python, l'équipe DevOps a réussi toutes les migrations et modifications de toutes les bases de code plusieurs semaines avant la date limite. L'équipe informatique de l'organisation a signalé que toutes les équipes sont actives sur GitHub et que les référentiels Bitbucket ont été archivés.

À propos de l'auteur <! -: blieberman, Directeur ->

Ben Lieberman est actuellement directeur du groupe de livraison Perficient Inc., DevOps. Le Dr Lieberman possède plus de vingt-cinq ans d'expérience en développement de logiciels et de systèmes dans un large éventail d'industries, y compris la finance, le gouvernement, les télécommunications, les sciences de la vie, les services de voyage et les systèmes de lancement spatial. Il est très expérimenté sur plusieurs sujets de développement de logiciels, y compris l'analyse des exigences, l'analyse et la conception de systèmes, le développement de systèmes sécurisés, la gestion de la configuration et le déploiement automatisé (alias DevSecOps). Il possède également une expérience de développement direct dans plusieurs langages, notamment les langages de codage Java, C #, C ++ et Salesforce (APEX), et travaille directement avec les équipes de développement sur des pratiques de livraison agiles. Dr. Lieberman est un écrivain professionnel accompli avec un livre («The Art of Software Modeling», Auerbach Publishing) et plus de trois douzaines d'articles informatiques professionnels à son actif. Le Dr Lieberman est titulaire d'un doctorat en biophysique et génétique de l'Université du Colorado, Anschutz Medical Center, Denver, Colorado.

Plus de cet auteur




Source link