Votre workflow sous steroïdes avec Gitlab-CI

Savez-vous pourquoi un système d'intégration continue est un élément primordial pour un bon workflow ? Connaissez-vous plus particulièrement les possibilités qu'offre Gitlab ? Quelle utilisation peut-on faire d'un CI lorsque l'on bosse avec Symfony et en quoi peut-il nous permettre de franchir un cap en productivité et en qualité ?

Revenons déjà sur ce qu'est l'intégration.

Historiquement, lorsque l’on conçoit une solution, il y a une première étape de conception, où l’on s’efforce de créer la solution qui correspond à la demande.

Après cette phase, qui peut être plus ou moins longue, arrive le moment où tout est prêt, et où il faut rassembler le travail de chacun et connecter la solution au reste du SI. Et c’est le moment de la roulette russe. Soit tout se passe bien et l’intégration va très vite, soit les soucis s'enchaînent et l’intégration peut prendre plus longtemps que la conception de la solution, et même échouer lamentablement.

Dans les années 90, un nouveau paradigme pour le développement est apparu : l’eXtreme Programming. Parmi les différents outils, XP a apporté l’intégration continue pour pallier à ce type de problématiques. Avec cette pratique, il n’est plus question d’attendre la fin du projet pour vérifier sa conformité avec le reste du SI.

Le principe est de d’augmenter la fréquence des tâches d’intégration, afin de les réaliser au moindre changement du code source. Pour cela, il faut :

• utiliser un outil de contrôle de version
• automatiser le processus de build
• rédiger des tests automatisés
• effectuer les contrôles qualité de la base de code
• non régression

De plus, le fait d’exécuter les tests de façon automatisée à chaque changement de la base de code permet de détecter les éventuelles régressions, qui étaient une des principales pertes de temps dans un projet informatique. Pour nous aider à automatiser ces tâches, nous avons essayé plusieurs outils depuis 10 ans (bitbucket, Stash, Github pour git, Jenkins, Bamboo, CircleCI pour la CI), et nous sommes arrêtés sur gitlab depuis plusieurs années déjà.

Attardons-nous sur Gitlab

Gitlab est principalement un outil de contrôle des sources basé sur git. Il permet de collaborer plus efficacement avec le système de Merge Request (équivalent des PR sur GitHub). Pourquoi Gitlab ? En plus des fonctionnalités standards de ce type d’outil, les raisons qui nous ont fait adopter Gitlab sont :

• le fait que l’on puisse auto-héberger la version CE ;
• le fait que l’outil soit complètement open source ;
• l’intégration des process DevOps, notamment au niveau de l’intégration continue.

En effet, là où l’intégration continue passe par des services tiers sur GitHub, Gitlab propose tous les outils pour automatiser cette partie via GitlabCI, avec la notion de pipeline.

Le concept CI de Gitlab est architecturé autour de jobs, qui sont des tâches uniques comme la création d’un build ou l’exécution de tests. Il est possible d’agglomérer des jobs en stages, qui sont un ensemble de jobs qui seront exécutés en parallèle. Une pipeline désigne en fait un ensemble de stages.

A quoi ressemble une pipeline "standard" ? En général on a une première stage de build/install, puis une de test et une dernière de deploy. Ici, par exemple, on a une pipeline basique pour un projet en GO.

Un des points positifs de Gitlab est la possibilité d’utiliser un serveur bare-metal comme serveur d’intégration continue, ce qui permet soit d’utiliser un serveur sous-utilisé par ailleurs, ou d’installer un serveur puissant qui va multiplier les jobs lançables en simultané.

Maintenant, quels outils peut-on utiliser avec Gitlab pour améliorer notre workflow de développement ?

Build

Pour commencer, chez Troopers, on travaille beaucoup avec Docker. La première chose que font nos pipelines est de surveiller l’image sur laquelle on construit l’application. Si celle-ci a bougé, alors on la recompile. Comment ? On fait un hash du fichier Dockerfile et on regarde si notre registre connaît une image taguée avec ce hash. Sinon, on va build l’image et la push dans le registry sous ce tag. Ainsi, on a toujours à disposition une image à jour pour notre application.

/.gitlab-ci.yml

/ci/build_job.sh

Contrôle qualité

Le second job que l’on va lancer est lié aux contrôles qualité. Chez nous, nous faisons majoritairement du PHP avec le framework Symfony, ainsi que du React pour la partie front. Une des missions les plus faciles à mettre en place dans un CI est de vérifier que les conventions de codage et de qualité sont respectées. En PHP, on peut faire ça avec pas mal d’outils comme PHPMD, php-cs-fixer, php-metrics, etc. Nous avons donc créé une stage spécifique de contrôle qualité qui exécute chacun de ces tests dans un job dédié, et donc exécuté en parallèle. On peut voir si chaque build passe ou non, et nous pouvons mettre à disposition un patch de correctifs fourni par exemple par php-cs-fixer.

/.gitlab-ci.yml

Tests

Une seconde stage est réservée à l'exécution des tests automatisés. Chez Troopers, nous utilisons beaucoup PHPUnit pour les tests unitaires, et aussi Behat pour les tests comportementaux. PHPUnit est extrêmement rapide, et nous permet d'avoir un retour quasiment instantané sur la validité de nos PRs. Par contre, les tests Behat sont beaucoup plus longs à s'exécuter. Le but étant de tester l'application comme le ferait un utilisateur réel, il faut booter l'application, lui brancher une base de donnée avec un jeu de test, émuler un navigateur pour valider le fonctionnement du javascript, etc.

Pour cela, nous nous basons sur Docker pour être capable de lancer un environnement complet. C'est de toute façon la technologie que l'on utilise pour travailler en local. Il suffit donc d'ajouter un job en début de pipeline pour compiler l'image de base, puis d'y envoyer le code source de la PR qui va être testée. Nous avons un docker-compose.yml dédié à la stack de test, qui embarque les images de Selenium.

/.gitlab-ci.yml

./ci/parrallelBehat.sh

Push

Une fois que les stages précédentes sont passées, alors le code est considéré comme valide, il est donc inclus dans notre image Docker et celle-ci est push dans le registry.

/.gitlab-ci.yml

Code Reviews et App Reviews

Parmi les bonnes pratiques de développement, il y en a une en particulier qui s’est imposée : les Code Reviews.

Étroitement lié au concept de Pull Request, il s’agit de faire en sorte qu’un développeur tiers relise le travail d’un collègue afin de détecter les points améliorables. Les Codes Reviews sont donc un super outil pour réduire la dette technique et améliorer la qualité globale d’une base de code. De plus, ils permettent de continuer à se former en continu en bénéficiant des retours des autres développeurs.

Pourquoi ne pas pousser ce concept plus loin ?

En effet, le Code Review permet de s’assurer de la qualité du code source livré, mais ne permet pas de vérifier que le changement dans la base de code soit cohérent avec la demande initiale. De plus, ça ne permet pas de vérifier que le design est respecté.

L’impact des Code Reviews est en fin de compte relativement limité. C’est pour ça que je vais vous parler des App Reviews.

Le principe est que, lorsque qu’une PR est ouverte, on puisse relire les changements de code, mais aussi accéder à la version proposée, déployée dans un environnement temporaire.

Le but est de faire intervenir un designer afin qu’il s’assure que les maquettes qu’il a conçu soient respectées et que l’ergonomie corresponde à ce qu’il avait imaginé.

Le product owner peut lui aussi s’impliquer, pour vérifier que la fonctionnalité correspond à l’user story qu’il a rédigé en amont.

Une fois qu’un développeur, un designer et un product owner ont review la PR et accepté celle-ci, on est sûr que la fonctionnalité est conforme, on peut donc merge la PR dans le tronc commun. Cette façon de procéder permet de se passer de recette en fin de sprint, tous les éléments ayant déjà été revus au fil de l’eau.

De pair avec tout cela, on a également le Stop Review qui a pour rôle de détruire la stack lorsque la PR est fermée, afin de libérer le serveur. Ce job est lancé automatiquement.

Maintenant, en quoi Gitlab nous aide à mettre en place ce type de procédé ?

Tout d’abord grâce aux jobs de déploiement. Il est possible de configurer un job dédié au déploiement de notre application. Par exemple chez Troopers, nous utilisons de plus en plus CleverCloud pour l’hébergement de nos applications. Nous passons aussi de plus en plus sous docker pour la construction de l’infra. Du coup, il est possible de construire un container contenant notre code source, de le monter pour exécuter les tests, puis de le push dans un registry (par exemple celui fourni par Gitlab), pour le déployer via docker-compose, swarm, ou sur n’importe quel IAAS. Nous allons détailler ici un job qui permet de déployer une prod, une preprod, ainsi que toute Merge Request qui contient une feature, sur CleverCloud, et de supprimer l’environnement automatiquement lorsque la MR est fermée.

Quid de Github et des Github Actions ?

Le système de CI de GitHub est facile à utiliser tant pour les débutants que pour les utilisateurs expérimentés. Il est également très bien intégré avec les autres services de GitHub. De plus, GitHub Actions est très flexible et peut être utilisé pour automatiser un large éventail de tâches de CI/CD. Nous ne sommes pas de grands fans de l’écriture des règles ce CI en yaml, mais c’est le cas tant dans Gitlab que dans Github. À titre personnel, j’ai quand même tendance à préférer la syntaxe Gitlab, mais c’est probablement lié au fait que je la maitrise mieux. Il est possible dans les deux systèmes d’héberger soi même des “runners”, qui permettent de lancer les jobs de CI. Ça peut être un choix judicieux si vous avez des compétences d’Ops, et permet d’économiser pas mal de budget, les coûts de CI étants facturés à la minute sur les runners fournis par Github et Gitlab.

En conclusion, que peut-on dire de Gitlab ?

Pour conclure, Gitlab apporte des outils d'intégration continue assez complets. Tant pour les check qualité, de testing, les apps reviews et de déploiement automatisés.

Si Github répond bien à vos besoins, mon opinion est que le rachat par Microsoft n'est pas une raison suffisante pour en partir. Sachez que la version saas de Gitlab est hébergée sur azure, et que Github, même avant ce rachat, est une solution propriétaire et centralisée. Rien n'a changé.

Maintenant, si vous cherchez quand même à quitter Github, Gitlab est une excellente alternative que l'on utilise depuis plusieurs années et qui nous comble parfaitement chez Troopers.