Intégration et déploiement en continu (CI/CD) avec GitHub Actions.
GitHub a sorti une nouvelle version en bêta de son service Actions. Publié pour la première fois en 2018, il est voué à l’organisation de workflows en liaison avec des événements. Sa principale nouveauté est le support de l’intégration et du déploiement en continu (CI/CD). La version finalisée était attendue pour la mi-novembre 2019.
Les workflows sont constitués d’au moins un et d’éventuellement plusieurs jobs qui peuvent être planifiés ou activés par un événement. Une instance de votre workflow s’exécute lorsque tel ou tel événement préconfiguré se produit. Vous pouvez voir les jobs, actions, logs et status pour chaque exécution de workflow.
Les workflows : job, step, runner and co
Le fichier YAML définit la configuration de votre workflow avec au moins un job. Ce fichier se trouve à la racine de votre repository GitHub dans le répertoire .github/workflows. Un job est une tâche constituée d’étapes. Chaque job s’exécute dans une nouvelle instance de l’environnement virtuel. Vous pouvez établir les règles de dépendance définissant dans un fichier de workflow comment les jobs doivent s’exécuter.
Les jobs peuvent s’exécuter en parallèle ou être dépendants du statut d’un job précédent et s’exécuter de manière séquentielle – ou synchrone. Un workflow peut, par exemple, avoir deux jobs séquentiels qui compilent et testent le code, avec le job de test qui est dépendant du statut du job de compilation. Si le job de compilation échoue, celui de test n’a aucune raison de s’exécuter… puisqu’il n’y aura rien à tester. Un step – ou une étape – est un ensemble de tâches exécutées par un job. Chaque étape d’un job s’exécute dans le même environnement virtuel, permettant aux actions de ce job de partager des informations via le système de fichiers associé. Ces steps peuvent exécuter aussi bien des commandes que des actions.
Un runner est un service GitHub en attente continuelle des jobs à exécuter dans chaque environnement virtuel. Lorsqu’un job s’exécute, il exécute les actions du dit job et reporte son avancée, ses logs et les résultats finaux à GitHub. Les runners n’exécutent qu’un seul job à la fois. Un événement est une activité spécifique qui déclenche l’exécution d’un workflow. L’activité peu, par exemple, avoir comme origine un commit vers un dépôt ou un résultat de build ou encore une pull request depuis GitHub. Vous pouvez également configurer un workflow à exécuter lorsqu’un événement externe se produit.
GitHub Actions (https://github.com/features/actions) est un outil permettant d’automatiser certaines actions sur la plateforme de partage de code.
Les workflows s’exécutent dans un conteneur ou une machine virtuelle. Cette nouvelle version de GitHub Actions supporte plus de langages et de frameworks : C/C++, Go, Java, .NET (VB .Net, C#, F#, …), Node.js, PHP, Python, Ruby, Rust côté langages, Android et iOS côté système d’exploitation. Pour les applications multi-conteneurs, l’ensemble du service web et de la base de données associée peut être testé simplement en ajoutant le terme “ docker-compose ” au fichier de workflow. Le but d’Actions reste le même qu’avant : faciliter l’automatisation de la création, du test et du déploiement de projets sur toutes les plates-formes système (Linux, Windows, Mac OS, Android…). Les dépôts publics seront aussi supportés. Les workflows de type Actions peuvent être déclenchés en réaction à des événements pendant tout le cycle de développement. Les applications GitHub, toutes sans exception, peuvent à présent ajouter leurs propres événements personnalisés, dans l’objectif de répondre à des besoins spécifiques, propres à chaque projet. GitHub Actions permet de publier et de consommer facilement des paquets du GitHub Package Registry ou de tout autre registre. La publication de paquets et de conteneurs est un élément clef dans tout workflow CI/CD. Actions permet d’automatiser les workflows sur ses propres machines virtuelles gérés dans le Cloud. Il faut pour cela installer le runner Actions sur les VM concernées et les enregistrer dans le service Actions. L’avantage est que les tâches exécutées sur ces runners auto-hébergés le sont gratuitement. GitHub Actions devrait prochainement être disponible pour les clients GitHub Enterprise Server, avec une option pour des déploiements sur le site en conservant le code et les paquets dans les centres de données pendant que GitHub organise les workflows. GitHub Actions est actuellement en bêta fermée. Du coup, les développeurs qui souhaitent le tester doivent s’inscrire sur la plate-forme, à cette adresse : https://github.com/features/actions. Le système étant actuellement en bêta, le service n’ouvre pas directement les portes, puisque l’automatisation est réalisée sur ses propres serveurs. Comme certaines tâches demandent beaucoup de puissance, la montée en charge doit être gérée correctement, d’autant que la fonction sera disponible pour tout le monde, y compris les utilisateurs qui ne paient pas. Bref, GitHub ne souhaite pas voir s’écrouler tout ou partie de son service. D’après ses dirigeants, Actions serait la plus grande évolution « depuis l’introduction de la pull request ». C’est un changement important pour GitHub, qui va pour la première fois permettre d’exécuter du code conçu par ses utilisateurs au lieu de se contenter de l’héberger. GitHub Actions doit permettre aux développeurs d’automatiser leur workflow ainsi que de partager celui-ci avec la communauté.
Nouveautés et améliorations diverses
Les autres nouveautés et améliorations concernent plusieurs points. Tout d’abord, les builds matriciels (matrixed builds) permettent de tester facilement en parallèle plusieurs versions d’un projet. Il suffit pour cela d’ajouter quelques lignes au fichier YAML, GitHub se charge du reste. Les logs en direct offrent des retours détaillés sur l’avancement de la compilation. Ces logs sont transférés à la console Actions qui affiche leur statut en temps réel. La syntaxe de GitHub Actions a été simplifiée afin de gérer plus aisément les workflows basés sur YAML. Les actions et les workflows peuvent être réutilisés via leur référence de dépôt. Il est ainsi possible de les regrouper pour former des workflows plus complexes et plus puissants. Ils peuvent être écrits en JavaScript ou créés sous forme d’Action container et interagir avec des API GitHub et des API publiques. Cette nouvelle version automatise également d’autres tâches communes du workflow, comme le tri, la gestion des éventuels problèmes, l’automatisation des publications ou la collaboration avec d’autres développeurs. GitHub a détaillé les autres fonctionnalités à venir ou mises en place sur sa plate-forme. La plate-forme s’enrichit ainsi d’un outil de détection des tokens (https://help.github. com/en/articles/about-token-scanning) de sécurité laissés par inadvertance dans le code mis en ligne sur GitHub et il arrive en effet que des organismes ou entreprises exposent par inadvertance leurs identifiants de connexion dans le code, ce qui peut être quelque peu gênant. GitHub étend également ses alertes de sécurité aux langages Java et .NET (C#, VB and co) et ouvre l’accès à son API Security Advisory qui agrège les informations collectées par GitHub sur les différentes vulnérabilités connues.
Des notifications peuvent être envoyées lorsque l’exécution d’un workflow est terminée. Elles présentent le statut de l’exécution du workflow : réussite, échec ou annulation.
Partage et automatisation
Le fonctionnement de GitHub Actions est basé sur le principe des triggers – ou déclencheurs – qui permettent d’invoquer de manière automatique certaines fonctions, les fameuses Actions, conçues ou non par la communauté afin de les exécuter de manière automatique sur la plateforme. Il est ainsi possible de mettre en place un message automatisé de bienvenue lorsque, par exemple, un nouveau contributeur propose pour la première fois une modification sur un projet open source. Il pourra être accueilli spécifiquement et redirigé automatiquement vers certaines ressources essentielles au dit projet. Toute autre fonction est possible, pour peu qu’elle existe … ou qu’on la crée. Il est aussi possible d’automatiser la mise en production d’un projet en prévoyant un “ chemin automatisé ” – dit pipeline – combinant plusieurs actions et déclencheurs afin de déployer automatiquement du code sur plusieurs Cloud providers. L’outil GitHub Secret Vault permet lui de stocker de manière sécurisée les tokens d’accès aux différents services et de les intégrer dans les actions. Ces actions sont donc des suites d’instructions écrites par les développeurs et exécutées par GitHub dans des containers. Comme elles sont partagées, vous pouvez récupérer des actions développées et mises au point par la communauté si elles répondent à vos besoins. Sinon, vous aurez à les écrire vous-même.
Les services tiers d’intégration en continu disponibles pour GitHub : https://github.com/marketplace/category/continuous-integration.
Intégration et livraison en continu
GitHub Actions a repris le concept d’intégration en continue – ou continuous integration (CI) – mais sans aucun service tiers, en l’intégrant à ses serveurs et en lui apportant une interface graphique rendant son accès plus simple. Cette nouvelle possibilité pour les développeurs consistant à mettre en place des déclencheurs sur leur workflow leur permet de faire du CI/CD dans GitHub. GitHub Actions utilise des conteneurs Docker pour gérer les capacités d’extension du service. GitHub Actions offre aux développeurs qui l’utilisent la possibilité de créer des builds, des packages, de publier, mettre à jour et déployer un projet dans n’importe quelle langue – sur GitHub ou tout autre système externe – sans avoir à exécuter le code. L’autre grand avantage de GitHub Actions est la possibilité de partager ces flux de travail avec la communauté GitHub. Cela ouvre également la porte de GitHub aux non-développeurs qui pourraient y voir un moyen pour automatiser les workflows associés au développement, comme la sécurité et l’exploitation. GitHub compare fréquemment Actions à l’app Raccourcis d’Apple, mais en version code de projet à exécuter. L’idée est loin d’être nouvelle, mais sur GitHub il fallait avoir recours à des services tiers pour faire cela. GitLab, concurrent de GitHub et champion de l’intégration en continu, en a fait sa fonction phare. La différence entre les deux est l’interface permettant de créer une automatisation sans avoir à apprendre un quelconque langage. Une version scriptable est néanmoins disponible pour des besoins avancés ou simplement pour les développeurs qui préfèrent cette approche.
L’évolution de l’agilité et du DevOps
Les développeurs pensent généralement en termes de pipelines (chaînes d’exécution) pour la livraison logicielle, mais un modèle bâti sur des événements est plus ouvert et plus flexible car il est capable d’exécuter des fonctions à partir de notifications, d’entrées utilisateur ou de capteurs. Comme le dit si bien un certain Rod Johnson, créateur du Spring Framework et CEO d’Atomist : « GitHub Actions place la gestion des événements au centre de la livraison logicielle. » GitHub Actions permet donc aux utilisateurs, des développeurs en l’occurrence, d’exécuter des actions et traitements dans le Cloud de GitHub. Ceux-ci sont déclenchés par un événement de type commit ou pull request. GitHub Actions s’intègre très bien, par exemple, à Terraform de HashiCorp (Cf. l’article paru dans L’Informaticien n°180) afin de vérifier automatiquement les erreurs de configuration. Rappelons que Git (https://git-scm.com/), le système de contrôle de code source distribué de Linus Torvalds, est essentiel à la programmation moderne, mais il est bien plus que cela encore. Git est essentiel pour toutes les opérations de type DevOps. GitHub le reconnaît sans ambages et, avec GitHub Actions, transforme ses services Git en pipeline de workflow DevOps. Avec une autre fonctionnalité de GitHub Action, les Matrix builds, vous pouvez tester vos programmes sous Linux, Mac OS, Windows, des containers et des versions d’exécution multiples simultanément. Cela vous permet également de tester en parallèle diverses versions de votre projet. Une pile DevOps complète comprend des outils pour configurer des systèmes avec des programmes DevOps tels que Chef, Puppet, Ansible ou Salt. Vous avez aussi besoin d’un contrôle de version de logiciel, ce qu’offre déjà GitHub. Et vous devez packager le programme avec Docker ou d’autres systèmes à base de container. Vous devez ensuite tester la nouvelle version de votre logiciel. L’étape suivante consiste à le déployer avec un programme tel que Jenkins. Après cela, le programme sera exécuté avec Kubernetes, par exemple. Enfin, vous contrôlez tout avec des packages tels que Elasticsearch, Kibana Stack, Logstash ou Prometheus. GitHub sait que cela ne se résume pas à juste ajouter du CI/CD et à tester. GitHub ne considère pas les CI/CD Actions comme des concurrents d’autres programmes CI/CD tels que GitLab CI, AWS CodeDeploy ou Jenkins.
Si GitHub Actions est gratuit pour les repositories open source publics, le service propose un paiement à l’utilisation pour les privés.
Le serveur d’automation open source leader du marché, Jenkins, propose des centaines de plugins permettant de supporter la construction, le déploiement et l’automatisation de l’exécution de chaque projet.
Tarif
GitHub Actions est gratuit pour les repositories open source publics. En ce qui concerne les privés, Actions propose un paiement à l’utilisation. Si vous réalisez l’exécution avec votre propre matériel ou un autre Cloud, dans ce cas l’utilisation des runners auto-hébergés d’Actions est gratuite. Ceci est vrai jusqu’au 13 novembre, lorsque le service Action ne sera plus en version bêta, il ne sera alors gratuit pour toutes et tous.
Artifact
Les artifacts sont les fichiers créés pendant les processus de compilation et de testing. Les artifacts peuvent, par exemple, inclure des fichiers binaires ou de package, des résultats de test, des copies d’écran ou des fichiers de log. Les artifacts sont associés à l’exécution du workflow, selon le moment où ils ont été créés, et peuvent être utilisés par un autre job ou déployés.
Notifications pour l’exécution de workflow
Si vous autorisez les notifications par mail ou via le Web pour les GitHub Actions, vous recevrez une notification lorsque n’importe quelle exécution de workflow qui s’est déclenchée est terminée. La notification comportera le statut de l’exécution du workflow, ceci incluant les exécutions réussies, celles qui ont échoué et, enfin, celles annulées. Vous pouvez aussi choisir de recevoir une notification seulement lorsque l’exécution d’un workflow a échoué.
Migrer les workflows GitHub Actions du HCL vers la syntaxe YAML
Le support de la syntaxe HCL dans les GitHub Actions est considéré comme obsolète (deprecated) depuis le 30 septembre 2019. Du coup, tous les workflows que vous avez créés en employant la syntaxe HCL devront être mis à jour ou plutôt réécrits en YAML, la nouvelle syntaxe.
CD/CI
L’intégration en continu est une pratique de développement logi‑ ciel consistant à poster fréquemment les modifications du code dans un dépôt (repository) partagé. Le déploiement en continu s’appuie forcément sur l’intégration en continu. Lorsque le nouveau code est “ commité ” (validé et enregistré) et a passé vos tests d’intégration ‑ en continu ‑, le code est déployé automatiquement en production. Avec les GitHub Actions, vous pouvez créer des workflows de déploiement personnalisés afin de déployer automatiquement votre code sur n’im‑ porte quel Cloud, service auto‑hébergé ou plate‑forme depuis votre dépôt. Le déploiement en continu fait gagner beaucoup de temps aux développeurs en automatisant le processus de déploiement et en déployant de nouvelles versions du code testé et plus ou moins stable plus rapidement. L’ensemble permet aussi de détecter et de résoudre plus rapidement les bugs.
Limites d’utilisation
Le dépassement éventuel des limites à l’utilisation peut résulter en mise en file d’attente, plantages à l’exécution ou interruption avant la fin du traitement. Ces limites sont fortement susceptibles de changer, le service n’étant encore disponible qu’en bêta. Les limites en question sont les suivantes : vous pouvez exécuter jusqu’à vingt workflows en parallèle par dépôt logiciel et jusqu’à mille requêtes d’API en une heure à travers toutes les actions d’un repository. Chaque job d’un workflow peut s’exécuter pendant une durée allant jusqu’à 6 heures. Vous pouvez exécuter jusqu’à vingt jobs en parallèle par dépôt tous workflows confondus. En plus de cela, les GitHub Actions ne doivent normalement pas être utilisés pour le cryptomining ou l’utilisation de logiciel réseau sans serveur. Enfin, GitHub ne fournit plus de support pour le HCL, mais seulement pour la syntaxe YAML.