Devriez-vous utiliser les actions Github pour l’intégration continue (CI) ? – Informatique CloudSavvy

L’intégration continue est cruciale pour tout référentiel actif qui nécessite une construction et des tests de routine. Github prend en charge les pipelines CI sous la forme d’actions Github, des builds qui s’exécutent dans le cloud, automatiquement, avec juste un peu de configuration.

Qu’est-ce que l’intégration continue ?

Alors que certaines bases de code, comme certaines applications Web, peuvent être déployées directement à partir de leurs fichiers source, d’autres nécessitent un traitement supplémentaire, une compilation et, surtout, des tests unitaires. Ces builds peuvent être compliqués et même gourmands en ressources dans le cas de langages comme C++.

L’intégration continue est le processus d’automatisation des tests et de création de nouveaux commits pour votre code source. Généralement, cela est utilisé avec des logiciels comme Jenkins exécutés sur un « serveur de construction » qui gérera la compilation proprement dite.

La compilation automatisée de code est un service tellement utile pour les équipes logicielles qu’il est désormais proposé par les fournisseurs de cloud, y compris Github, où il s’intègre parfaitement avec le reste de leurs services.

Que sont les actions Github ?

Les actions Github sont des tâches basées sur le cloud qui peuvent être utilisées pour automatiser votre référentiel. Ils sont couramment utilisés pour exécuter des builds automatisés pour les nouveaux commits ou versions, ce qui peut être utile pour les tests logiciels continus. Cependant, ils peuvent également être utilisés pour l’automatisation non liée à l’IC, comme le traitement des problèmes et des demandes d’extraction, l’exécution cron tâches ou déclencher des commandes en fonction d’actions dans votre compte.

En ce qui concerne CI, les actions Github sont très utiles. La plupart des pipelines CI vous obligent à configurer des logiciels complexes comme Jenkins ou à utiliser un service cloud spécifique comme AWS CodePipeline. Les actions Github sont très simples et vous demandent simplement de valider un fichier de configuration pour .github/workflows/ pour activer une action.

En plus de cela, Github est généralement en mesure de déterminer le type de projet que vous réalisez et de proposer des suggestions de configuration d’action à partir de sa bibliothèque d’exemples. Par exemple, ce projet Java était opérationnel avec des builds automatisés en quelques minutes seulement avec quelques ajustements mineurs pour

Vous pouvez avoir plusieurs actions dans le même dépôt ; par exemple, vous souhaitez peut-être configurer des builds automatisés pour chaque commit sur le dev branche, mais vous ne voulez que des builds pour chaque nouvelle version taguée sur la master branche. Vous pouvez créer deux fichiers YAML distincts avec des critères différents.

Bien que les actions soient très utiles pour effectuer des builds et des tests, elles peuvent également exécuter des commandes et se connecter à d’autres services, ce qui leur permet également d’automatiser les processus de livraison et de déploiement. Par exemple, vous pourriez avoir une action sur le release branch prend chaque nouvelle version étiquetée et la télécharge sur vos serveurs pour le déploiement.

Par défaut, les builds Github Actions publieront les artefacts de build (tout ce qui a été produit par le processus de build) dans un fichier zip pour chaque exécution. Cela fonctionne bien si vous n’exécutez que des tests, mais si vous souhaitez effectuer une livraison automatisée, vous pouvez également les configurer pour publier automatiquement de nouvelles versions ou pousser vers un registre de packages/conteneurs comme NPM ou le hub Docker.

La configuration exacte de votre référentiel variera en fonction de votre processus de construction, mais Github fait un bon travail en fournissant des exemples solides pour commencer, et la configuration générale est en grande partie la même. Si vous souhaitez en savoir plus sur la mise en route de GH Actions, vous pouvez lire notre guide sur leur configuration.

Tarification des actions Github

Heureusement, Github a l’argent pour parrainer des logiciels open source, donc les actions sont entièrement gratuit pour les dépôts publics. Vous pouvez les utiliser autant que vous le souhaitez ou stocker autant d’artefacts de construction que vous le souhaitez. Il n’y a pas de limite stricte, sauf si vous êtes abusif, tout comme le reste de Github.

Pour les référentiels privés, chaque compte dispose automatiquement de 2000 minutes de temps de construction chaque mois, ce qui est très généreux. C’est presque un jour et demi de construction continue, donc vous devriez faire des constructions très longues – ou des tonnes de commits – pour atteindre ce nombre. Vous êtes plus susceptible d’atteindre la limite de stockage de 500 Mo pour les comptes gratuits. Cependant, si vous construisez sur chaque validation, avec de longs temps de construction et que vous vous engagez souvent, vous pouvez épuiser ce nombre.

Les utilisateurs de Github Pro (4 $/mois) bénéficient de 3 000 minutes et de 1 Go de stockage, tout comme les organisations utilisant le plan Github Team, qui est de 4 $ par utilisateur et par mois.

Github Enterprise, qui coûte 21 USD par utilisateur et par mois, offre 50 000 minutes de construction, soit 35 jours consécutifs de construction, ce qui vous permet d’exécuter des constructions 24h/24 et 7j/7, et plus encore.

Si vous dépassez un forfait, vous serez simplement facturé pour les minutes supplémentaires utilisées. Les tarifs sont assez justes, avec 2000 minutes supplémentaires coûtant 16 $.

Devriez-vous utiliser des actions ou votre propre serveur de build ?

CI/CD commence par le suivi du contrôle de version. Les builds automatisés sont généralement exécutés pour chaque validation ou version majeure, et la plupart des systèmes de serveur de build autonomes, comme Jenkins ou TeamCity, s’intégreront à votre git référentiel pour fournir cette fonctionnalité.

Cela rend la propre solution CI de Github assez utile en comparaison – elle est intégrée directement dans le service que vous utilisez déjà et est extrêmement simple à mettre en place et à faire fonctionner. Tout ce que vous avez à faire est de valider le fichier de configuration de construction sur votre .github dossier, et Github le récupérera et l’exécutera. Alors que les services autonomes peuvent être utiles pour les déploiements d’entreprise, pour l’utilisateur moyen, la simplicité d’utilisation des actions Github est plus facile que même l’installation d’un serveur de construction personnalisé.

Les actions Github peuvent également être utilisées pour plus que de simples builds automatisés. Ils prennent en charge tous les types d’automatisation de référentiel, y compris le traitement des problèmes et des demandes d’extraction.

Cela dit, les actions Github ne sont pas aussi complètes que l’exécution de votre propre serveur, et si vous effectuez de nombreuses versions régulières ou compliquées, vous devriez envisager de configurer un serveur Jenkins. Si vous effectuez de nombreuses versions gourmandes en CPU, Jenkins peut également être bon pour cela, mais Github Actions prend également en charge l’utilisation de votre propre serveur pour exécuter des versions.

EN RELATION: Comment installer et utiliser Jenkins pour créer un pipeline CI/CD