Intégration, livraison, déploiement le tout en continu

Avant de vous expliquer comment nous appliquons ces méthodes chez JETPULP, il nous paraît judicieux de faire un petit rappel sur ces 3 pratiques que sont l’intégration continue, la livraison continue et le déploiement continu.

L’intégration continue (Continuous Integration aka CI) est une pratique d’ingénierie logicielle dans laquelle des modifications isolées du code sont immédiatement testées et signalées lorsqu’elles sont ajoutées à la base de code.

Les logiciels d’intégration continue sont utilisés pour automatiser le test et construire une trace documentaire.

Pour que la CI soit efficace et apporte toute sa plus-value, les défauts doivent être détectés et résolus rapidement, autrement dit « les voyants doivent toujours être au vert. »

La livraison continue (Continuous Delivery aka CD) est une pratique consistant à automatiser l’ensemble du processus de publication du logiciel. L’idée est de faire la CI, puis de préparer et de suivre automatiquement la publication vers la production.

Le résultat souhaité est que toute personne ayant des privilèges suffisants pour déployer une nouvelle version peut le faire à tout moment en un ou quelques clics. En éliminant presque toutes les tâches manuelles, les développeurs deviennent plus productifs.

Le déploiement continu (Continuous Deployment) est une version encore plus poussée de la livraison continue dans laquelle chaque modification du code source est déployée automatiquement, sans autre approbation que celle du développeur qui a fait la revue de code (pour (re)lire l’article c’est par ici). Un logiciel de  CI / CD prend en charge l’exécution de tous les tests et le déploiement du code en production, tout en informant l’équipe sur les résultats de chaque événement important.

Nous utilisons le logiciel de CI intégré à Gitlab qui nous donne entière satisfaction :

• son interface utilisateur est élégante et compréhensible
• les comptes rendus d’exécution sont directement accessibles depuis GitlabCI (cf. image 2)
• il est facile à mettre en oeuvre car toute la configuration se situe dans le fichier .gitlab-ci.yml  du projet
• son architecture basée sur des runners, la parallélisation des jobs et l’utilisation de docker permet d’être rapide, de scaler et de l’exécuter sur différents environnements
• il est orienté vers le Continuous Delivery avec ses notions d’environnement et de stages multiples
• la version Community Edition est Open Source

Selon les projets, nous mettons en place un premier stage d’analyse statique de code (aka lint ou code sniffer). Cette analyse nous permet de vérifier automatiquement certaines règle de codage (code style), voir d’identifier des erreurs d’exécution possibles. Nous utilisons également des outils comme PHPCS ou PHPSTAN  pour le PHP ou bien Eslint pour le javascript et scss-lint pour le sass.

S’en suit un stage de tests, avec des tests PHPUnit ou bien des tests javascripts. Les jobs GitlabCI s’exécutant dans des containers docker, cela laisse une entière souplesse pour les projets qui comprennent plusieurs technos (php, javascript, etc.. ).

GitlabCI nous permet même de faire du déploiement continu en exécutant Capistrano à la fin du Pipeline de CI.