À propos des migrations d’entreprise vers GitHub Actions
Pour migrer votre entreprise vers GitHub Actions un système existant, vous pouvez planifier la migration, terminer la migration et mettre hors service les systèmes existants.
Ce guide aborde les points à prendre en considération concernant les migrations. Pour plus d’informations sur l’intégration de GitHub Actions dans votre entreprise, consultez Présentation de GitHub Actions à votre entreprise.
Planification de votre migration
Avant de commencer à migrer votre entreprise vers GitHub Actions, vous devez identifier les flux de travail qui seront migrés et la façon dont ces migrations affecteront vos équipes, puis planifiez comment et quand vous terminerez les migrations.
Appel à des spécialistes de la migration
GitHub peut vous aider avec votre migration, et vous pouvez également bénéficier de l'achat de GitHub Professional Services. Pour plus d’informations, contactez votre représentant dédié ou [L’équipe commerciale GitHub](https://github.com/enterprise/contact).
Identification et inventaire des cibles de migration
Avant de pouvoir migrer vers GitHub Actions, vous devez avoir une compréhension complète des flux de travail utilisés par votre entreprise dans votre système existant.
Tout d’abord, dressez un inventaire des workflows existants de build et de mise en production dans votre entreprise, collectez des informations sur les workflows qui sont activement utilisés, ceux qui doivent être migrés et ceux qui peuvent être omis.
Découvrez ensuite les différences entre votre fournisseur actuel et GitHub Actions. Cela vous aidera à évaluer les éventuelles difficultés liées à la migration de chaque workflow, et en quoi votre entreprise pourrait rencontrer des différences sur le plan des fonctionnalités. Pour plus d’informations, consultez « Migration vers GitHub Actions ».
Avec ces informations, vous serez en mesure de déterminer les flux de travail que vous pouvez et souhaitez migrer vers GitHub Actions.
Déterminer l’impact des migrations sur l’équipe
Quand vous changez les outils qui sont utilisés dans votre entreprise, vous influez sur la façon de travailler de votre équipe. Vous devez prendre en compte la façon dont le déplacement d’un flux de travail à partir de vos systèmes GitHub Actions existants affectera le travail quotidien de vos développeurs.
Identifiez les processus, les intégrations et les outils tiers qui seront affectés par votre migration, puis établissez un plan pour les mises à jour que vous devrez éventuellement effectuer.
Réfléchissez à la façon dont la migration peut affecter vos préoccupations de conformité. Par exemple, vos outils existants de balayage des informations d'identification et d'analyse de sécurité fonctionneront-ils avec GitHub Actions, ou devrez-vous utiliser de nouveaux outils ?
Identifiez les portes et les contrôles dans votre système existant et vérifiez que vous pouvez les implémenter avec GitHub Actions.
Identification et validation des outils de migration
Les outils de migration automatisés peuvent traduire les flux de travail de votre entreprise de la syntaxe du système existant vers la syntaxe requise par GitHub Actions. Identifiez les outils tiers ou contactez votre représentant dédié ou L’équipe commerciale GitHub pour vous renseigner sur les outils que GitHub peut fournir. Par exemple, vous pouvez utiliser GitHub Actions Importer pour planifier, définir l’étendue et migrer vos pipelines CI vers GitHub Actions à partir de différents services pris en charge. Pour plus d’informations, consultez « Automatisation de la migration avec GitHub Actions Importer ».
Une fois que vous avez identifié l’outil qui va automatiser vos migrations, validez-le en l’exécutant sur certains workflows de test et en vérifiant que les résultats sont conformes à vos attentes.
Les outils automatisés devraient pouvoir migrer la majorité de vos workflows, mais vous aurez probablement besoin d’en réécrire manuellement un petit nombre. Estimez la quantité de travail manuel que cela implique.
Choix d’une approche de migration
Identifiez l’approche de migration la mieux adaptée pour votre entreprise. Les petites équipes seront peut-être en mesure de migrer tous leurs workflows en une seule opération, selon une approche de substitution complète. Pour les grandes entreprises, une approche itérative s’avérera sans doute plus réaliste. Vous pouvez choisir de confier la gestion de la migration complète à un organe central ou vous pouvez demander aux différentes équipes s’assurer elles-mêmes la migration de leurs propres workflows.
Nous préconisons une approche itérative qui mêle une gestion active et le libre-service. Commencez par un petit groupe d’utilisateurs précoces qui peuvent faire office de conseillers internes. Identifiez une poignée de workflows suffisamment complets pour représenter l’étendue de votre activité. Collaborez avec vos utilisateurs précoces pour migrer ces flux de travail vers GitHub Actions, itération si nécessaire. Cela donnera aux autres équipes la confiance nécessaire pour migrer leurs workflows.
Ensuite, mettez GitHub Actions à disposition de votre organisation élargie. Fournissez des ressources pour aider ces équipes à migrer leurs propres flux de travail GitHub Actionset informer les équipes quand les systèmes existants seront mis hors service.
Enfin, informez les équipes qui utilisent toujours vos anciens systèmes qu’elles disposent d’un délai précis pour effectuer leurs migrations. Vous pouvez mettre en avant la réussite des autres équipes pour les rassurer quant à la faisabilité et à l’intérêt de la migration.
Définition de votre programme de migration
Après avoir décidé d’une approche de migration, créez une planification qui décrit quand chacune de vos équipes migrera leurs flux de travail vers GitHub Actions.
Pour commencer, fixez la date à laquelle votre migration doit être terminée. Par exemple, vous pouvez prévoir de terminer votre migration d’ici la fin du contrat qui vous lie à votre fournisseur actuel.
Ensuite, établissez un programme en collaboration avec vos équipes qui tienne compte de votre échéance sans sacrifier leurs objectifs d’équipe. Examinez la cadence de votre activité et la charge de travail de chaque équipe à laquelle vous demandez de migrer. Coordonnez-vous avec chaque équipe pour comprendre leur programme de livraison et élaborez un plan qui permet à l’équipe de migrer ses workflows à un moment qui ne nuira pas à leurs activités.
Migration vers GitHub Actions
Lorsque vous êtes prêt à démarrer votre migration, traduisez vos flux de travail existants à GitHub Actions l’aide des outils automatisés et de la réécriture manuelle que vous avez planifiée précédemment.
Vous pouvez aussi conserver les anciens artefacts de build de votre système existant, peut-être en écrivant un processus scripté pour archiver les artefacts.
Mise hors service des systèmes existants
Une fois la migration terminée, vous pouvez penser à la mise hors service de votre système existant.
Vous pouvez exécuter les deux systèmes côte à côte pendant une certaine période, tandis que vous vérifiez que votre GitHub Actions configuration est stable, sans dégradation de l’expérience pour les développeurs.
Enfin, désactivez et arrêtez les anciens systèmes, puis veillez à ce que personne au sein de l’entreprise ne puisse remettre les anciens systèmes en route.