Préambule
Le CI/CD est un ensemble de pratiques permettant de packager, tester et déployer une application de façon continue, quelque soit le moment ou la période.
Elle se base sur une chaine d’intégration qui automatiquement va déployer cette même application.
L’intégration continue (CI) est l’ensemble des étapes qui permettent de publier une nouvelle version d’un site ou d’une application. Ça peut passer par le lancement automatique des tests lors d’ajout de code, mais aussi le test de la qualité de celui-ci etc.
On branche souvent cette chaîne à des outils comme SonarQube pour la qualité du code, le framework de tests du projet etc.
Ceci permet à l’application d’être testée au fur et à mesure et de vérifier qu’elle respecte bien nos conditions de qualité et de fiabilité avant d’arriver en production.
Le déploiement continu (CD) est la suite de cette même chaîne d’intégration, c’est à dire que l’on ne déploie des versions que si elles ont été validées par la chaine d’intégration continue. Le déploiement continu part aussi du principe que notre paquet est fiable.
Déploiement continu sous-entend aussi que l’on est capable de faire un retour arrière (rollback) à tout moment.
Ces pratiques font partie de la mouvance DevOps qui fusionne le développement logiciel ainsi que la partie infrastructure et en particulier ici le déploiement.
Celle-ci s’est accélérée avec l’apparition des conteneurs type Docker pour héberger les applications.
Retour en 2010
En 2010, le paysage du web était bien différent de celui que l’on connait de nos jours. Tous les outils que l’on utilise de façon naturelle aujourd’hui n’existaient pas ou étaient tout au début de leur implémentation.
A cette période nous nous basions sur ce que WordPress faisait :
- SVN pour le versionning
- Versionning de tout ce qui est dans le code, que se soit à nous ou non
- Branche de développement, trunk, tags etc.
Mais aussi :
- Développement sur un serveur central, upload en FTP
- Mises à jour de WordPress, des plugins et des thèmes à la main, avec tous les problèmes que cela peut engendrer
Le déploiement est aussi du même acabit, en tant qu’agence nous devons nous adapter à des clients différents, avec des SI différents.
C’est à dire qu’en fonction des cas, nous pouvons avoir soit un accès FTP, soit un zip à disposer quelque part, soit un email à faire avec le site etc.
De plus, chaque hébergement est différent, avec ses propres limitations, ses propres accès.
Ceci mène à une politique de déploiement pour chaque projet, des identifiants en pagaille et des processus écrits mais pas toujours faciles à suivre ad-hoc.
Chaque mise à jour des sites était dépendante de la connexion internet du poste, du logiciel FTP utilisé.
Ce processus n’était pas fiable, les fichiers supprimés sur SVN ne l’étaient pas sur le site distant de façon automatique, on retrouvait alors d’anciens fichiers sur l’hébergement.
Chaque mise à jour était la possibilité de casser des choses si un fichier était mal uploadé, si une coupure réseau apparaissait, si le disque distant était plein ou tout autre problème.
De plus l’activité de maintenance devait aussi connaitre et apprendre à déployer ses modifications.
Je ne compte plus les fois où l’on a entendu :
Tu peux déployer pour moi ? Je ne sais pas comment on fait.
Je n’ai pas pu deployer, les accès n’étaient pas à jour.
Mais aussi tous les problèmes de sécurité que cela pouvait apporter, souvent le même accès pour tout le monde. L’accès étant en SFTP user/mot de passe dans quasiment tous les cas, le partage et le stockage des credentials étaient un problème.
2013 : Changement de logiciel, changement de paradigme
En 2013 le changement de SVN à GIT a permis de modifier la façon dont les déploiements étaient faits, désormais il est possible de se connecter sur le serveur et faire un git pull ou de checkout une branche.
Ce seul changement a permis de créer des scripts de déploiement, de permettre de faire des actions pré et post déploiement.
Le déploiement est déporté sur le serveur du client, cependant la procédure reste dépendante d’un humain.
Il faut que les accès soient bien remplis, que l’on soit autorisé à se connecter sur les serveurs.
La sécurité aussi est un problème, il est très facile de se retrouver avec le dossier .git accessible à la racine et de checkout tout le projet localement.
Ce processus reste manuel, incertain, difficilement réversible.
Les nouveaux outils : Composer, grunt, gulp, webpack
Afin de rendre la maintenance et la gestion des sites à un certain niveau il faut commencer à industrialiser ses développements. Ne pas versionner le code des autres est une première étape et composer répond à ce besoin. Mais aussi changer la manière dont le CSS et JS sont codés, compilés et optimisés.
Les outils de compilation et les outils de gestion de dépendance sont devenus de plus en plus présents et ont permis de répondre à beaucoup de problématiques.
Cependant, ces outils amènent une complexité qui n’existait pas précédemment, car ils sont dépendant de :
- La machine de la personne qui les utilise
- Les versions de Node, PHP
- Des différents crendentials pour aller chercher les dépendances
Ce qui ne permet pas de créer un package prêt à déployer en production.
Il est facile d’oublier de compiler le CSS/JS, mais aussi d’avoir la mauvaise version du logiciel en local ce qui rend les déploiements plus lents, plus hasardeux et plus complexes.
Ces outils ont amené rapidement des questions comme
- qui compile ?
- comment ?
- à quel moment ?
- est-ce que l’on versionne le code compilé ?
Plusieurs équipes travaillent sur le produit final, autant sur le PHP pur, sur le HTML/CSS/JS et ce ne sont pas les mêmes personnes.
Ces mêmes personnes n’ont pas besoin de savoir qu’il y a 3 scripts à lancer avant de pouvoir déployer le code.
Cet état intermédiaire a vite mené a des problématiques de code mal compilé ou non compilé, de scripts qui passaient il y a 6 mois mais qu’une mise à jour de tel ou tel outil a rendu impossible à exploiter.
2017 : l’automatisation avec Buddy
Le besoin d’un outil de déploiement se faisait grandement sentir, il n’était plus possible de faire les actions localement ou sur le serveur du client, beaucoup de temps a été perdu. Que se soit en développement ou en maintenance, personne n’était satisfait.
Des outils existaient, mais ils semblaient trop techniques, avec une interface trop compliquée ou totalement incompréhensible.
Il fallait aussi que cet outil soit suffisamment flexible pour s’adapter aux nombreux outils que nous utilisons, aux environnements des clients, aux hébergements etc.
En 2017 au détour d’une discussion avec Alexandre, l’un de nos développeurs, Buddy.works est mentionné.
La solution semblait magique, déployer partout, tout le temps, quelques soient les technologies web présentes.
Le principe de Buddy est le même que les autres logiciels de CI/CD avec un twist : exécuter des actions dans un pipeline à travers des machines docker.
Le pivot central du fonctionnement est un repository git : github, gitlab, bitbucket tout provider qui a des webhooks.
Ces pipelines sont executés en fonction de diverses conditions, mais il peut être simplement branché sur des commits du repository.
Ce simple principe permet de s’adapter à presque tous les projets, hébergements, situations.
Un pipeline classique serait :
- Compiler le PHP avec composer dans la version de PHP de PROD
- Compiler le CSS et le JS avec webpack dans la version de Node de développement
- Envoyer les sources compilées vers le serveur de PROD en RSYNC
- Vider les caches sur le serveur de PROD
- Envoyer une notification Slack pour dire que tout s’est bien passé
Les intégrations
La force de Buddy est de pouvoir être adapté à des situations diverses et variées.
Vous utilisez AWS et ses beanstalkApp pour déployer vos applications ? Une action existe
Vous avez besoin de lancer des tests avant de déployer ? Des actions existent
Vous voulez pinger des services externes/internes (New Relic, Sentry …) lors des déploiements ? Des actions existent.
Vous avez besoin de créer un zip, l’envoyer sur un serveur, envoyer un email à quelqu’un ? Des actions existent.
Ce changement ne s’est pas fait en un seul jour, les nouveaux projets sont passés sur cet outil rapidement et la méthode de déploiement a changé au fur et à mesure.
Mais dès que cet outil a été mis en place, les équipes ont demandé de l’avoir à chaque fois.
L’une de ses plus grandes forces est l’interface : mettre en place un pipeline de déploiement prend quelques minutes, c’est ergonomique, clair et bien fait.
Difficile de ne pas trouver son bonheur dans le catalogue d’actions.
Il est également possible d’utiliser n’importe quelle image Docker du repository officiel ou son propre repository.
Une API
Les devs ne sont pas en reste, une API CLI et HTTP sont disponibles permettant de manipuler Buddy facilement.
Au lieu d’aller dans l’interface il est possible de déclencher et gérer les projets depuis une application externe.
Cerise sur le gâteau, vous pouvez l’installer sur votre serveur (on premise) pour pouvoir avoir votre propre IP par exemple. Mais à vous de gérer la mise à l’échelle et les mises à jour.
Unifier les déploiements
Les déploiements sont désormais globalement unifiés, même s’il ya des cas particuliers avec certains clients (vpn, bastion etc.)
- La branche de développement est liée à l’environnement de développement, chaque commit déploie une nouvelle version sur cet environnement
- L’environnement de preproduction est lié à la branche principale
- L’environnement de production est lié aux tags
Chaque pipeline exécute à minima les actions
- Compilation PHP
- Compilation CSS/JS
- Modification de la version pour Sentry
- Déploiement du code( rsync, déploiement atomique, image docker etc.)
- Ping sur Slack
Si quelque chose se passe mal, alors une notification Slack est envoyée avec le journal d’exécution.
Ceci a permis de créer des pipelines à dupliquer pour les déploiements :
Avec cette manière de fonctionner, les équipes sont assurées de voir leur travail déployé sur le serveur, proprement et comme en production.
Chaque déploiement se ressemblant, on est sûr que le code présent sur l’environnement est celui que l’on a poussé.
Tout de même adapté aux clients
Bien que la méthode de déploiement ait été unifiée, parfois nous ne pouvons pas avoir accès aux environnements ou devons créer un package pour le client.
Pas de problème, nous utilisons alors la méthode de la « branche construite » directement empruntée à WordPress VIP et que nous utilisons sur les projets VIP.
Le principe est simple, au lieu d’envoyer le package tel quel vers les environnements, les fichiers normalement ignorés sont versionnés dans une branche idoine, par exemple main devient main-built.
Mais il est aussi possible de créer le package puis de le positionner sur un FTP, un bucket S3, l’envoyer par email, par message Slack etc.
Tout type de scénario peut être envisagé, avec des actions manuelles, des heures et jours de déploiement autorisés etc.
Ce qui a changé désormais
Désormais c’est un automatisme d’avoir ces pipelines, on ne se pose plus la question « puis-je déployer ? ».
On peut déployer à toute heure et revenir en arrière si besoin.
Buddy n’est pas le seul produit à proposer ce genre de fonctionnalités, on peut le retrouver avec les github Actions, gitlab CI ou sur les différents cloud providers.
Avec les processus de déploiement et de compilation qui se complexifient, l’utilisation d’un tel outil est incontournable de nos jours.
Que vous utilisiez des actions simples comme envoyer en FTP votre site, passer par un cloud provider, des images Docker ou autre, cette solution s’adapte à vos besoins.
Si vous n’utilisez pas d’outil de déploiement actuellement, je vous encourage grandement à le faire, ceci est le premier pas dans l’automatisation du reste de votre pile logicielle.
Il n’est pas nécessaire de tout implémenter directement, mais commencer par là permet au final de réussir à avancer doucement.
Les activités de création mais aussi de maintenance des sites y gagnent.
