Imaginez deux équipes de développement.
La première prépare une nouvelle version de l’application.
Le développeur termine sa tâche. Quelqu’un vérifie le code. Ensuite, il faut lancer les tests. Quelqu’un prépare le paquet. Une autre personne se connecte au serveur. Puis il faut effectuer plusieurs actions manuelles, vérifier la configuration et surveiller le système après le déploiement. Si tout se passe bien, la nouvelle version est disponible.
La deuxième équipe travaille différemment.
Le code arrive dans le dépôt. Les tests, l’analyse de qualité et les contrôles de sécurité se lancent automatiquement. Le système construit la version de l’application, la déploie sur l’environnement de test, effectue des vérifications supplémentaires, puis, si certaines conditions sont remplies, peut la déployer en production. Si quelque chose tourne mal, le déploiement est interrompu ou le système peut revenir à la version précédente.
Les deux équipes créent des logiciels.
Mais une seule a construit un processus reproductible de livraison logicielle.
Et c’est précisément cela, le CI/CD.
"Ça fonctionne en production" n’est pas encore un processus mature
Beaucoup d’entreprises mesurent le succès avec un critère très simple : l’application fonctionne.
C’est évidemment une condition de base.
Mais à mesure que le système se développe, de nouvelles questions apparaissent :
- À quelle vitesse pouvons-nous déployer un correctif ?
- À quelle fréquence pouvons-nous publier de nouvelles fonctionnalités ?
- Combien d’actions manuelles effectuons-nous à chaque déploiement ?
- Chaque développeur peut-il lancer le processus de déploiement selon les mêmes règles ?
- Savons-nous quelle version fonctionne actuellement ?
- Sommes-nous capables de revenir à la version précédente ?
- Après le déploiement, vérifions-nous automatiquement que le système fonctionne correctement ?
- Avons-nous de la supervision ?
- Savons-nous que le déploiement a causé un problème avant que le client ne le signale ?
Ce sont des questions liées à la livraison logicielle, et pas seulement à la programmation elle-même.
CI et CD - deux éléments d’un même processus
CI, c’est-à-dire Continuous Integration, signifie l’intégration continue des changements.
En pratique, il s’agit de faire en sorte que les changements arrivent souvent dans le dépôt commun et soient vérifiés automatiquement.
Un pipeline typique peut exécuter, entre autres :
-
la compilation ou la construction de l’application,
-
les tests unitaires,
-
les tests d’intégration,
-
le linting,
-
l’analyse statique du code,
-
le scan des dépendances,
-
les contrôles de sécurité,
-
la génération des artefacts de déploiement.
Ainsi, un problème peut être détecté avant que le code n’atteigne la production.
CD, c’est-à-dire Continuous Delivery ou Continuous Deployment, concerne l’étape suivante - la livraison des changements.
Selon le modèle adopté, le système peut préparer une version prête à être déployée ou la déployer automatiquement après le passage de certains contrôles.
C’est une distinction importante.
Le Continuous Delivery ne signifie pas forcément le déploiement automatique de chaque changement en production.
Cela peut simplement signifier que chaque version est préparée de manière reproductible pour le déploiement.
Pourquoi les déploiements manuels deviennent-ils un problème ?
Un déploiement manuel n’est pas forcément mauvais.
Dans un petit projet, cela peut être tout à fait suffisant.
Le problème commence lorsque le processus grandit avec l’application.
D’abord, nous avons une personne qui sait comment déployer le système. Puis un deuxième serveur arrive. Ensuite, l’environnement de test. Puis la base de données, le cache, les files d’attente, le stockage, plusieurs services et des API externes. À cela s’ajoutent différentes configurations pour le développement, les tests et la production.
Après quelques années, le processus peut ressembler à ceci :
"D’abord, lance X, puis change le paramètre Y, ensuite redémarre le service Z, mais avant cela, fais une sauvegarde de la base. Et si une erreur apparaît, appelle la personne qui a effectué le dernier déploiement."
Ce n’est plus un processus. C’est une connaissance cachée dans la tête d’une personne. Et c’est précisément là que le risque augmente.
L’automatisation ne sert pas seulement au confort des développeurs
Souvent, le CI/CD est présenté comme un outil qui améliore le confort des développeurs. C’est vrai, mais ce n’est qu’une partie du tableau.
L’automatisation de la livraison augmente avant tout la reproductibilité du processus.
Si un humain effectue le déploiement, il est possible qu’il fasse quelque chose d’un peu différent à chaque fois.
Si c’est le pipeline qui le fait, on peut définir une séquence exacte d’étapes.
La même version.
Les mêmes tests.
Les mêmes contrôles.
Les mêmes règles.
C’est particulièrement important dans les projets développés par plusieurs personnes ou plusieurs équipes.
Les tests avant le déploiement sont plus importants que la vitesse de déploiement
L’automatisation sans tests peut seulement faire apparaître les erreurs plus rapidement.
C’est pourquoi un pipeline bien conçu ne devrait pas être seulement un mécanisme : "code → production".
Il devrait être un système de contrôle qualité.
Selon le projet, il peut inclure :
- Tests unitaires - vérifiant des éléments individuels de la logique.
- Tests d’intégration - vérifiant la coopération des composants.
- Tests end-to-end - simulant de véritables scénarios d’utilisation.
- Tests de sécurité - vérifiant entre autres les dépendances et les vulnérabilités connues.
- Tests de performance - nécessaires là où la prise en charge d’une certaine charge est importante.
Toutes les applications n’ont pas besoin de toutes ces couches dans la même mesure.
Et c’est important.
Le CI/CD ne consiste pas à ajouter le plus grand nombre possible d’outils au pipeline.
Il s’agit d’adapter les contrôles au risque du système concerné.
Que se passe-t-il lorsqu’un test échoue ?
C’est l’une des questions les plus importantes de tout le processus.
Un pipeline mature doit avoir des règles clairement définies.
Si un test critique échoue, la version ne devrait pas être considérée comme prête à être déployée.
Si une analyse de sécurité détecte un certain niveau de risque, le pipeline peut arrêter le processus.
Si le build échoue, il n’y a rien à déployer.
Cela semble banal. Mais ce sont justement ces "garde-fous" automatiques qui font que la qualité ne dépend pas uniquement de la mémoire et de la précision humaine.
Et si le déploiement échoue malgré tout ?
Même le meilleur processus n’élimine pas toutes les erreurs. C’est pourquoi le deuxième élément d’une livraison mature est la possibilité d’un retour contrôlé en arrière.
Le rollback peut signifier un retour à l’artefact précédent, à l’image du conteneur ou à la version de l’application. Mais un problème important apparaît ici. Le rollback du code ne signifie pas toujours le rollback des données.
Si la nouvelle version a modifié la structure de la base de données, la situation devient plus compliquée.
C’est pourquoi les migrations de bases de données doivent être conçues de manière à ce que tout le processus soit aussi sûr et réversible que possible, ou au moins compatible avec la version précédente de l’application.
C’est l’un des exemples qui montrent qu’un CI/CD professionnel est un problème d’architecture, et pas seulement de configuration d’un outil.
Blue-green, canary et autres stratégies de déploiement
Dans les systèmes plus exigeants, il n’est pas nécessaire de basculer immédiatement tous les utilisateurs vers la nouvelle version. On peut utiliser différentes stratégies de déploiement.
Déploiement blue-green
Deux versions de l’environnement fonctionnent en parallèle.
L’une gère le trafic, l’autre est préparée à prendre le relais.
Après vérification positive, le basculement a lieu.
L’avantage est la possibilité de revenir rapidement à l’environnement précédent.
L’inconvénient peut être une plus grande consommation d’infrastructure.
Déploiement canary
La nouvelle version est d’abord déployée auprès d’une petite partie des utilisateurs ou du trafic.
Si la surveillance ne révèle aucun problème, le périmètre du déploiement peut être augmenté progressivement.
Cela limite la portée potentielle d’une erreur.
Cela exige toutefois une infrastructure adaptée, de la surveillance et une manière de gérer le trafic.
Feature flags
Une fonctionnalité peut être déployée dans le système, mais rester désactivée pour les utilisateurs.
Ainsi, le déploiement du code et l’activation de la fonctionnalité deviennent deux processus distincts.
Cela offre un meilleur contrôle, en particulier lors de changements importants.
Cela ne signifie toutefois pas que les feature flags soient une solution pour chaque projet. Leur excès peut lui aussi accroître la complexité du système.
Surveillance après le déploiement
On peut exécuter tous les tests. On peut avoir un excellent pipeline. On peut déployer une nouvelle version sans la moindre erreur. Et quelques minutes plus tard, l’application peut commencer à se comporter différemment sous une charge réelle.
C’est pourquoi le processus ne devrait pas s’arrêter au déploiement. Il faut de l’observability, c’est-à-dire la capacité de comprendre ce qui se passe à l’intérieur d’un système en fonctionnement.
Selon l’architecture, cela comprend entre autres :
-
les logs,
-
les métriques,
-
le tracing,
-
la surveillance de l’infrastructure,
-
la surveillance de l’application,
-
les alertes,
-
les informations sur les erreurs,
-
les indicateurs métier.
Il ne s’agit pas de tout collecter. Il s’agit de pouvoir répondre aux questions importantes à partir des données.
L’application fonctionne-t-elle ?
Fonctionne-t-elle plus lentement qu’avant ?
Le nombre d’erreurs a-t-il augmenté ?
Quel service génère le problème ?
Le problème concerne-t-il tous les utilisateurs ou seulement une partie ?
100 déploiements par jour n’est pas toujours l’objectif
Le titre de cet article parle de 100 déploiements par jour, mais il ne s’agit pas de fixer ce nombre comme objectif.
Dans un système interne mis à jour une fois par mois, il n’a pas de sens de viser artificiellement des centaines de déploiements. En revanche, dans un système développé de manière très intensive, une telle fréquence peut être techniquement possible.
L’élément clé est la capacité à livrer des changements en toute sécurité, et non le nombre de déploiements lui-même. C’est une différence fondamentale.
La maturité du processus ne se mesure pas à la fréquence de nos déploiements, mais à la manière dont nous pouvons les réaliser de façon prévisible et sûre.
Quand le CI/CD peut-il être un excès de forme sur le fond ?
Chaque application n’a pas besoin d’une infrastructure de déploiement complexe.
Si nous avons une petite application, une petite équipe et quelques déploiements par an, un pipeline élaboré peut coûter plus cher que les problèmes qu’il résout.
C’est également le cas de systèmes très spécifiques, où le déploiement nécessite un contrôle manuel pour des raisons de sécurité, de réglementation ou de nature de l’infrastructure.
C’est pourquoi l’architecture de delivery doit découler des besoins du système. Pas de la mode.
Quand l’automatisation des déploiements apporte-t-elle particulièrement beaucoup ?
Il vaut la peine d’y réfléchir surtout lorsque :
-
le système est développé régulièrement,
-
plusieurs personnes travaillent sur le code,
-
il existe plus d’un environnement,
-
les déploiements sont fréquents,
-
les déploiements manuels génèrent des erreurs,
-
le système est critique pour l’activité,
-
nous avons besoin d’un rollback rapide,
-
l’application comporte de nombreux composants,
-
des audits ou une trace des changements sont nécessaires,
-
le délai de livraison d’une fonctionnalité a une importance métier.
Dans de tels cas, un pipeline bien conçu peut être l’un des éléments les plus importants du processus de développement logiciel.
Le CI/CD ne corrige pas une mauvaise architecture
Il faut également le souligner.
On peut créer un excellent pipeline pour une mauvaise application.
Tester automatiquement un mauvais code.
Déployer automatiquement une mauvaise architecture.
Faire évoluer automatiquement un système mal conçu.
L’automatisation ne remplace donc ni l’architecture, ni les tests, ni les compétences de l’équipe.
Elle renforce le processus existant.
Si le processus est bon, elle aide à le faire évoluer.
Si le processus est mauvais, elle peut simplement exécuter plus vite de mauvaises choses.
À quoi ressemble un processus mature ?
Il n’existe pas de pipeline universel unique.
Mais un processus mature devrait posséder რამდენიმე propriétés de base.
Répétabilité - le déploiement s’effectue selon des étapes définies.
Automatisation - les machines exécutent autant que possible la part répétitive du travail.
Testabilité - les changements sont vérifiés automatiquement.
Sécurité - le processus comprend les contrôles de sécurité appropriés.
Observabilité - après le déploiement, on sait ce qui se passe dans le système.
Réversibilité - il existe une manière planifiée de réagir à un changement raté.
Traçabilité des changements - on sait quelle version a été déployée et à partir de quoi elle a été créée.
Contrôle d’accès - tout le monde ne peut pas déployer n’importe quoi en production.
C’est précisément à partir de tels éléments qu’émerge un processus professionnel de delivery logiciel.
Le changement le plus important commence par une autre question
Les entreprises demandent souvent : "À quelle vitesse pouvons-nous créer cette fonctionnalité ?"
Il vaut la peine d’ajouter une deuxième question : "À quelle vitesse et en toute sécurité pourrons-nous livrer les 50 prochaines fonctionnalités ?"
Car un déploiement unique peut être effectué manuellement. On peut même déployer une application manuellement pendant plusieurs années. Mais à mesure que le produit, l’équipe, le nombre d’utilisateurs et le nombre de changements augmentent, le coût d’une telle approche augmente lui aussi.
C’est pourquoi le CI/CD, les tests automatiques, la surveillance et les déploiements contrôlés ne sont pas seulement des solutions pour les grandes entreprises.
Ce sont des éléments de l’infrastructure du processus qui permettent de faire évoluer un logiciel sans ajouter de risque inutile à chaque changement suivant.
Et au final, c’est bien cela qui compte.
Pas 100 déploiements par jour.
Pas des outils à la mode.
Pas à propos du pipeline le plus complexe.
Seulement de la possibilité de dire :
« Nous avons un changement. Nous l'avons vérifié. Nous savons ce que nous déployons. Nous savons comment le surveiller. Et nous savons ce que nous ferons si quelque chose tourne mal. »
