L'intégration continue en pratique

Dans l’article précédent nous avions présenté GitHub et GitLab, nous allons maintenant montrer comment on actionne les CI en pratique.

GitHub et ses Actions

Pendant plusieurs années, GitHub n’intégrait pas de solution de CI et il fallait s’appuyer sur des services externes comme Travis CI ou CircleCI afin d’exécuter les tests automatiquement, ce qui était fastidieux à configurer car il fallait connecter deux services différents.

Ceci a changé à partir de 2018 quand GitHub a intégré un service de CI gratuit nommé Actions. Sa grande force est la possibilité d’utiliser des recettes existantes, par exemple pour installer PHP et des modules en quelques lignes de configuration.

Pour les projets non publics (autrement dit les projets privés), GitHub offre 2 000 minutes d’utilisation des Actions par mois.

GitLab et sa CI

Dès le début de notre bascule sur GitLab, nous nous sommes appuyés sur son service CI afin de lancer automatiquement les tâches de tests (fonctionnels, unitaires ou E2E) et de vérification de la qualité du code (formatage et logique).

Les tests automatisés sont lancés par 4 serveurs physiques qui jouent le rôle de runner, chaque serveur attend en permanence que des tests soient en file d’attente. Dès qu’un test apparaît dans cette file d’attente, le serveur lance le test. Par exemple, chez Troopers les tests sont créés quand une demande de fusion (Merge Request) est ouverte dans GitLab.

Comme GitHub Actions, GitLab est en train de mettre en place un système de recettes réutilisables (les components) cependant cette fonctionnalité est encore en beta et nous n’avons pas encore tenté l’expérience. La documentation n’est pas très claire sur le résultat : est-ce que ça crée un ou plusieurs jobs sur la CI ?

Ouvre une nouvelle fenêtreGitLab.com (la plate-forme officielle) offre 500 minutes d‘utilisation par mois pour les projets privés.

GitHub Actions et GitLab CI en pratique

Afin de montrer la configuration en pratique, nous avons créé un projet qui contient un fichier PHP simple avec une spécificité : l’extension intl est nécessaire pour que PHP puisse l’exécuter.

La CI aura 2 rôles :

• vérifier que le script peut être exécuté sans erreur
• vérifier que la syntaxe du script est correcte, grâce à l’outil PHP-CS-Fixer

Les deux services sont configurés via des fichiers YAML dont la syntaxe est assez similaire.

Avec GitHub Actions

Fichier

Ouvre une nouvelle fenêtresource du script

Résultat dans une Ouvre une nouvelle fenêtrePull Request :

Comme vous pouvez le constater, l’utilisation des actions existantes de GitHub permet de faire des opérations complexes avec quelques lignes de code pour décrire les paramètres qui seront passés aux Actions déjà existantes.

Le mot-clé

Avec GitLab CI

Fichier

Ouvre une nouvelle fenêtresource du script

Résultat dans une Ouvre une nouvelle fenêtreMerge Request :

Quant à GitLab, aucune recette externe n’est utilisée, chaque étape doit être définie dans le fichier de configuration. En contrepartie, on voit exactement les étapes qui vont être réalisées par GitLab, alors qu’avec GitHub Actions, il faut aller voir dans le code source de

Afin de disposer d’un environnement PHP avec l’extension

1. construire une image Docker (notez qu’on fait un appel direct au programme
   )
2. pousser l’image sur le registry de GitLab
3. dans un second temps, récupérer l’image et lancer le test

Cela peut sembler contraignant, mais au final ça n’ajoute que 40 secondes dans le temps total de la CI (une fois que l’image a été construite, la CI ne la re-construit pas afin d’économiser du temps), ça fait peu de différence car nos CI tournent en moyenne pendant 10 minutes.

Alors qu’avec GitHub Actions, l’installation de l’extension intl n’a nécessité que 2 lignes de configuration. Nous espérons que les components de GitLab seront aussi performants que les actions de GitHub.

(note : il est aussi possible de lancer un conteneur Docker basé sur PHP puis d’installer l’extension

Pour des explications complètes, nous vous invitons à voir les exemples d’un article précédent : https://www.troopers.coop/blog/votre-workflow-sous-steroides-avec-gitlab-ci

Conclusion

GitHub Actions et GitLab CI sont des outils extrêmement puissants, on peut configurer toutes les opérations que l’on souhaite :

• lancer des batteries de tests
• vérifier notre propre code par des analyses statiques
• déployer des conteneurs Docker sur des serveurs Web
• compiler un projet React en site statique puis envoyer les fichiers sur un serveur Web
• générer un storybook et l’héberger via GitLab Pages, ce qui est plus rapide que de configurer un serveur Web
• déployer une application mobile via Expo EAS
• etc.

GitHub, avec son service Actions, offre une intégration fluide et de puissantes recettes prédéfinies qui réduisent significativement le temps et l'effort nécessaires à la configuration des environnements et à l'exécution des tests. GitLab, d’un autre côté, offre une transparence et un contrôle accrus sur les processus grâce à ses configurations détaillées, permettant aux équipes de comprendre et de gérer chaque étape du pipeline de CI/CD.