Qu'est-ce que GitHub Actions ? Une plateforme automatisée CI/CD

Intégrée à GitHub, la plateforme Actions sert à automatiser la conception, le test et le déploiement de logiciels. Appartenant à Microsoft, Github est un service d'hébergement pour le développement de logiciels utilisant Git, un programme de collaboration et de contrôle de version open source développé par Linus Torvalds. Git et GitHub sont déjà utilisés par de nombreux programmeurs comme base à leurs pratiques de développement, y compris les pipelines automatisés d'intégration et de déploiement continu (CI/CD) qui gèrent le cycle de vie du développement d'une application. Actions fournit ce que l'éditeur appelle une "API de cause à effet" : cette plateforme peut ainsi être utilisée pour automatiser toutes sortes de comportements basés sur différents déclencheurs.

Actions a été lancé en 2018. Il ne s'agit pas de la seule solution de CI/CD pour les projets basés sur GitHub ; d'autres, tels que Azure Pipelines et Jenkins, peuvent être préférées dans certaines situations. Mais comme Actions est intégré à la plateforme GitHub dans son ensemble, les utilisateurs n'ont pas à se soucier de l'infrastructure sous-jacente. Son flux de travail global est également conçu en tenant compte de GitHub, ce qui en fera une option attrayante pour beaucoup.

Le fonctionnement de GitHub Actions

L'une des meilleures façons de comprendre le fonctionnement d'Actions est de considérer la terminologie qui décrit ses composants individuels. Il en existe également un autre appelé "action" (petit "a") qui sera également évoqué. Examinons maintenant quelques-uns des composants de la plateforme :

- Event : Un événement est ce qui déclenche le pipeline automatisé dans Actions. Il peut être quelque chose de spécifique qui se produit dans un dépôt - un pull request ou un commit poussé, par exemple - ou un déclencheur programmé, un message envoyé à une API REST, ou même simplement une commande manuelle.

• Workflow : Chacun de ces événements peut déclencher un flux de travail, qui est le terme général pour un processus automatisé utilisé avec Actions : un workflow est utilisé pour déployer une application lorsqu'une nouvelle version est prête par exemple, ou pour ajouter des tags appropriés lorsque quelqu'un ouvre un ticket d'incident. Un flux de travail est défini dans un fichier YAML enregistré dans le répertoire .github/workflows de son dépôt (consulter la documentation GitHub pour la syntaxe). Ce fichier définit les événements qui peuvent déclencher le flux de travail, ainsi que les choses que vous voulez que le flux de travail fasse.

- Jobs : Les tâches traitées dans un workflow sont regroupées et chacune d'entre elles se déroulent dans un ordre à déterminer ; ce flux de tâche peut être constitué de plusieurs travaux s'exécutant en parallèle ou qui se succèdent dans un ordre prédéfini, ou encore d'une combinaison des deux. Il est aussi possible de créer des dépendances entre les travaux. Par exemple, il est possible d'avoir plusieurs tâches de conception exécutées en parallèle pour différentes architectures de puces. Une fois toutes ces tâches terminées, une suivante pourra se charger d'empaqueter toutes les conceptions.

- Actions : Une étape individuelle d'une tâche peut consister en un simple script shell, mais si on a besoin de quelque chose de plus complexe, il est également possible d'utiliser une action. Cette dernière consiste en un code qui interagit avec son dépôt GitHub ; on peut utiliser l'API de GitHub pour cela, ou n'importe quelle API tierce disponible. Les tâches exécutées par les actions peuvent aller du déploiement de code lorsqu'il est prêt pour la production à l'envoi d'un SMS d'alerte aux développeurs de garde pour traiter les problèmes urgents. Les actions peuvent être écrites pour être exécutées dans un conteneur Docker, mais ce n'est pas obligatoire. L'un des points clés des actions est qu'elles sont réutilisables. Alors que les appels de scripts shell peuvent être simplement inclus dans le fichier YAML qui définit son flux de travail, les actions sont des applications autonomes qui sont référencées dans le fichier YAML et peuvent être utilisées par plusieurs workflow au sein de votre organisation. Ce type de réutilisation est l'un des aspects les plus puissants des actions, et c'est ce qui les a rendues suffisamment importantes pour qu'elles servent d'homonyme aux actions GitHub dans leur ensemble. Vous pouvez également utiliser la grande variété d'actions créées par des tiers sur la place de marché GitHub Actions ; malgré leur nom, ces actions sont gratuites et en grande partie open source, et vous pouvez également contribuer à la place de marché avec vos propres actions.

- Runners : Une unité d'exécution est le serveur sur lequel s'exécute un travail. Chaque tâche au sein d'un worklflow dispose de son propre serveur d'exécution ; comme vous pouvez vous en douter, il s'agit généralement de machines virtuelles, fraîchement approvisionnées pour votre travail. GitHub fournit des machines virtuelles hébergées à cette fin (Ubuntu Linux, Microsoft Windows ou macOS), mais si vous avez besoin que votre travail s'exécute sur une configuration matérielle ou un système d'exploitation spécifique, vous pouvez héberger un serveur d'exécution vous-même.

Exemples de fonctionnement de GitHub Actions

La documentation de GitHub contient des exemples qui aideront à comprendre le fonctionnement d'Actions. Pour commencer, on peut tester son code sur un runner. Un autre cas montre comment travailler ave Actions à partir de l'interface de ligne de commande de GitHub. Un exemple qui va plus loin - et qui peut s'avérer particulièrement intéressant pour explorer la puissance de GitHub Actions - implique ce que le fournisseur appelle une stratégie matricielle. Dans ce type de workflows, des variables sont utilisées lors de la définition d'un travail pour concevoir plusieurs exécutions de tâches qui diffèrent en fonction des valeurs des variables. Comme le montre l'exemple détaillé de GitHub, il s'agit d'un bon moyen de tester automatiquement son code dans différentes langues ou versions de systèmes d'exploitation. Il est d'ailleurs tout à fait possible de modifier les valeurs des variables pour choisir de nouveaux environnements de test. Fireship.io propose d'autres exemples utiles d'Actions GitHub, notamment des démonstrations sur la façon de publier un paquetage sur NPM lorsque vous créez une nouvelle version, d'envoyer automatiquement des courriels, des messages Slack ou Discord pour informer les utilisateurs de la progression d'un travail, ou de planifier un travail en arrière-plan à un moment précis ou à des intervalles spécifiques.

Meilleures pratiques de sécurité pour les actions GitHub

Si vous exécutez Action sur du code dans un repo GitHub, vous travaillez certainement avec une base de code distribuée, ce qui entraîne des complications en matière de sécurité. L'éditeur recommande des bonnes pratiques pour garantir la protection de vos flux de travail :

- Utilisez des secrets pour les données sensibles : Vous ne devez jamais coder en dur des éléments tels que les mots de passe ou les données de connexion à l'API dans vos définitions de flux de travail. GitHub vous permet d'enregistrer de telles informations en tant que secrets cryptés ; en effet, si vous utilisez un secret pour générer une autre information qui devrait également être sécurisée, vous pouvez enregistrer cette valeur en tant que secret.

• Gardez un œil sur vos fichiers de flux de travail : Si un pirate parvient à modifier les définitions de vos flux de travail, vous pourriez ouvrir vos systèmes à l'infiltration ou à l'attaque simplement en exécutant un travail. Utilisez la fonction de propriétaires de code de GitHub pour réglementer l'accès aux répertoires dans lesquels vous conservez les fichiers YAML de vos flux de travail.

• Se prémunir contre les injections de scripts : Comme toute application pouvant accepter des données, les actions peuvent être utilisées de manière malveillante si un attaquant parvient à y introduire du code exécutable. Vous devez appliquer les mêmes techniques de codage défensif aux actions GitHub que celles que vous appliqueriez à tout autre code potentiellement sensible.

• Soyez prudent avec le code d'une tierce partie : Outre la place de marché Actions, il existe de nombreux autres endroits où les membres de la communauté partagent des actions et du code de flux de travail. Ces ressources peuvent être utiles, mais vous ne devez jamais intégrer du code tiers dans votre base de code sans réfléchir. Veillez à soumettre ces modules au même niveau d'examen de sécurité que tout autre code que vous mettriez en production.

Pour des informations plus approfondies sur la sécurité, consultez également le guide de GitHub sur le renforcement de la sécurité des actions GitHub.

Intégrer Actions à d'autres plateformes

GitHub étant une plateforme relativement ouverte et les flux de travail GitHub Actions étant décrits en YAML déclaratif, il existe plusieurs façons de les intégrer à d'autres plateformes :

• AWS : Vous pouvez réutiliser vos actions sur CodeCatalyst, le service de développement de logiciels géré par AWS, en utilisant un wrapper pour les transformer en actions CodeCatalyst similaires sur le plan conceptuel.

• Azure : Microsoft permet d'écrire un flux d'actions GitHub qui déploie du code sur la plateforme d'hébergement Azure App Service.

• Visual Studio : En ce qui concerne Microsoft, le vénérable IDE Visual Studio de la société dispose d'une extension qui vous permet de créer et de gérer des flux de travail GitHub Actions sans quitter l'éditeur.

• Google Cloud : Google a mis à disposition un certain nombre d'actions permettant d'intégrer du code stocké dans un dépôt GitHub à son service Google Cloud, notamment une action permettant de tirer parti de Cloud Deploy pour déployer du code en production.

Tarification

GitHub Actions est gratuit pour les tâches s'exécutant sur des runners standard hébergés par GitHub dans des dépôts publics, ou si l'on héberge soi même ses runners. Si vous utilisez un dépôt privé, vous bénéficiez gratuitement d'une certaine quantité de stockage et de temps de calcul, mais vous devez payer dès que vous dépassez ces limites. Il existe également des limites globales sur le nombre de tâches simultanées que vous pouvez exécuter en utilisant les runners hébergés par GitHub, ainsi que sur les requêtes API par heure et la durée d'exécution du flux de travail. Consultez la documentation de GitHub pour plus de détails.

Alternatives

Il existe d'autres outils sur le marché qui automatisent le processus CI/CD et occupent donc en grande partie le même espace que GitHub Actions. L'un des plus importants et des plus matures est sans doute Jenkins, un outil open source dont les origines remontent à 2004. Jenkins peut fonctionner avec des dépôts GitHub via des plugins - ainsi qu'avec du code dans un certain nombre d'autres environnements - et est généralement assez flexible, bien que la courbe d'apprentissage puisse être abrupte par rapport à GitHub Actions.

En général, la plus grande force de GitHub Actions est son intégration étroite avec GitHub. D'autres services d'hébergement ont leurs propres équivalents ; GitLab a GitLab CI, par exemple, et il y a aussi AWS CodeCataylst actions. Pour ceux qui recourent à GitHub et n'ont pas encore investi dans un outil multiplateforme comme Jenkins, GitHub Actions apparait comme un choix logique pour ses besoins d'automatisation des processus CI/CD.