Continuous Delivery

1Le jour de la release ne devrait pas faire peur

Le livre ouvre sur une scène que tout le monde a vécue : l'équipe au complet un weekend entier, les yeux rouges devant un écran à 2 h du matin, à essayer de comprendre pourquoi le déploiement coince. Les auteurs nomment trois mauvaises habitudes qui mènent là.

• Déployer à la main : chaque étape exécutée par une personne, avec des jugements à prendre au passage, donc une erreur humaine possible à chaque tour.
• Ne toucher un environnement proche de la prod qu'à la toute fin : la première fois que les ops voient le logiciel, c'est le jour de la mise en prod, et les surprises pleuvent.
• Configurer la prod à la main : un réglage modifié directement sur le serveur, jamais tracé, impossible à reproduire.

La phrase qui résume leur colère : « Livrer du logiciel est trop souvent un art ; ça devrait être une discipline d'ingénierie. » Leur preuve tient en une anecdote. Un de leurs clients mobilisait une équipe entière sept jours, weekend compris, pour chaque mise en prod, avec un taux de réussite médiocre. Après automatisation, la dernière mise en prod observée a pris sept secondes. Personne n'a rien remarqué, sauf que les nouvelles fonctions étaient soudain là. But du livre : rendre les releases ennuyeuses.

2Le pipeline de déploiement, du commit à la prod

C'est le concept central, celui qui donne son sous-titre au livre. Un sigle d'abord : la CI, l'intégration continue, c'est l'habitude de reconstruire et retester l'application à chaque changement pour la garder toujours en état de marche. Le pipeline de déploiement pousse cette idée jusqu'au bout.

Voici comment il marche. Chaque changement (code, configuration, environnement, données) déclenche une nouvelle instance du pipeline. Premier étage, le commit stage : on compile, on lance les tests unitaires rapides, on fabrique les binaires. Si ça passe, on obtient un « release candidate », un candidat à la mise en prod, rangé dans un dépôt d'artefacts. Étage suivant : les tests d'acceptance automatisés, qui vérifient que les fonctions métier marchent. Puis les tests manuels et la recette (UAT, la validation par des représentants des utilisateurs). Dernier étage : la release.

Le détail malin, c'est que le pipeline est un système à la demande. Un testeur, un ops ou un manager se sert lui-même : il choisit la version qu'il veut, l'environnement qu'il veut, et il appuie sur un bouton. Plus besoin de quémander un déploiement à un développeur ni d'attendre la nuit. La bonne métrique pour juger tout ça, empruntée à Mary et Tom Poppendieck : « Combien de temps faudrait-il à votre organisation pour déployer un changement d'une seule ligne de code ? »

3Si ça fait mal, fais-le plus souvent

C'est l'heuristique mère, celle qui infuse tout le livre, et la plus facile à retenir. Si une activité fait mal, ne la repoussez pas : faites-la plus souvent, et tout de suite.

L'intégration du code de plusieurs développeurs est pénible ? Intégrez à chaque commit, dès le premier jour du projet, au lieu d'accumuler pour une grande fusion douloureuse à la fin. Les tests font peur juste avant la release ? Testez en continu depuis le début. La doc est une corvée ? Écrivez-la au fil des fonctions. Le principe a un corollaire qu'ils appellent « avancer la douleur » : déplacer l'effort tôt dans le cycle, là où une erreur coûte le moins cher à réparer. Les auteurs le disent eux-mêmes : l'Extreme Programming (la méthode agile des années 2000 qui pousse à l'extrême des pratiques comme tester et intégrer en continu) applique déjà cette heuristique au développement. Leur livre applique la même au déploiement.

4Compile une fois, déploie partout pareil

Deux règles concrètes qui m'ont marqué, parce que je les vis tous les jours.

La première : ne compilez vos binaires qu'une seule fois. Le binaire fabriqué au commit stage est le SEUL qui voyage, à l'identique, à travers tous les environnements jusqu'en prod. Recompiler à chaque étape, c'est risquer une version de compilateur ou de bibliothèque différente, donc un binaire subtilement différent de celui qu'on a testé. La phrase exacte : « Les binaires déployés en production doivent être exactement les mêmes que ceux passés par les tests d'acceptance. » Certains pipelines vérifient même l'empreinte du binaire à chaque étage.

La seconde : déployez de la même façon partout. Un seul script de déploiement, le même pour le poste du développeur, la recette et la prod, juste paramétré par un fichier de config propre à chaque environnement. La conséquence est puissante : le chemin vers la prod a été testé des centaines de fois avant le jour J. Si un problème survient en prod, vous savez que c'est la configuration de cet environnement, jamais le script. Tout ça repose sur un troisième principe, simple et radical : tout ce qui sert à construire, déployer, tester et livrer va en gestion de version. Un nouvel arrivant doit pouvoir cloner le dépôt et tout reconstruire d'une seule commande.

5« Fini » veut dire « en production »

Combien de fois a-t-on entendu un développeur dire qu'une fonction est « finie » ? Pour les auteurs, une fonction n'est finie que lorsqu'elle apporte de la valeur à des utilisateurs. Pas quand le code compile, pas quand elle est « finie sur ma machine ». Et il n'y a pas de « fini à 80 % » : une chose est faite ou elle ne l'est pas.

Ça change qui porte la responsabilité. « Fini » ne dépend pas d'une seule personne : il faut des testeurs, des ops et des développeurs qui travaillent ensemble du début à la fin. Fini le développeur qui jette son code par-dessus le mur aux testeurs, qui le jettent aux ops le jour de la release. Toute l'équipe est responsable de la livraison.

Derrière, un autre principe, volé au mouvement lean et à W. Edwards Deming : « construire la qualité dedans ». Plus on attrape un défaut tôt, moins il coûte cher, et le moins cher de tous, c'est celui qu'on ne laisse jamais entrer en gestion de version. Conséquence directe : tester n'est pas une phase qu'on colle après le développement, c'est une activité continue qui appartient à tout le monde.

6Déployer n'est pas livrer

Voici le chapitre qui me sert le plus, et le moins daté du livre. L'idée : déployer (mettre le binaire en place) et livrer (le rendre visible aux utilisateurs) sont deux actes distincts. Les séparer rend le retour en arrière trivial et désamorce le risque de la release.

Trois techniques concrètes en découlent.

• Le blue-green : deux environnements de prod identiques, baptisés bleu et vert. Le routeur envoie tout le trafic vers le vert. On déploie la nouvelle version sur le bleu, on la chauffe, on la teste à blanc, puis on bascule le routeur vers le bleu. La bascule prend, je cite, « bien moins d'une seconde ». Un souci ? On rebascule sur le vert.
• Le canary (déploiement canari) : on déploie la nouvelle version sur une poignée de serveurs seulement, et le routeur n'y envoie qu'une petite fraction des utilisateurs. « Comme un canari dans une mine de charbon », ça révèle vite les problèmes sans toucher la majorité. Si les métriques sont bonnes, on élargit, sinon on coupe.
• Le rollback : revenir en arrière, soit en gardant l'ancienne version déployée prête à reprendre, soit en redéployant une version saine connue, avec le même processus testé cent fois.

Une règle d'or traverse le chapitre : un correctif d'urgence passe par le même pipeline que tout le reste. Contourner le tube « parce que c'est urgent », c'est livrer un truc non testé dans un environnement dont on ne connaît plus l'état.

7Les branches longues tuent l'intégration

C'est la position la plus tranchée du livre, celle qui fait encore débat. Un terme d'abord : une branche, en gestion de version, c'est une copie parallèle du code où l'on travaille à l'écart du tronc commun. Le verdict des auteurs : « les branches sont fondamentalement contraires à l'intégration continue. »

Le raisonnement est imparable. Si chacun travaille sur sa branche de fonctionnalité, alors par définition personne n'intègre son travail à celui des autres. On peut même faire de la CI sur chaque branche prise isolément, ça ne change rien : les branches divergent du tronc, et le jour de la fusion on récolte des conflits massifs. Leur conseil tient en une pratique : « commitez toujours sur le tronc, et au moins une fois par jour. »

Pour les gros changements qui font peur à intégrer d'un coup, ils proposent le branch by abstraction (de leur collègue Paul Hammant) : au lieu d'une branche, on introduit une couche d'abstraction dans le code et on remplace l'ancienne implémentation par la nouvelle petit à petit, sur le tronc, sans jamais casser le build. Quelques branches restent tolérées : la branche de release, et la branche jetable d'expérimentation.

Cette idée a vieilli dans un sens curieux. Git était jeune en 2010, et les auteurs s'en méfiaient pour l'entreprise (historique réécrivable, audit plus glissant). Git a gagné partout. Mais leur fond, développer sur le tronc plutôt que sur des branches longues, c'est exactement ce que le mouvement « trunk-based development » défend aujourd'hui.

8La base de données aussi se versionne

On parle beaucoup de déployer du code ; le livre rappelle que les données ont leur propre cycle de vie et survivent aux déploiements comme aux retours en arrière. La réponse : automatiser les migrations de base de données avec des scripts versionnés, un script « avancer » et un script « reculer » par version du schéma.

L'enjeu, c'est de découpler le changement de schéma du déploiement de l'application. Une migration bien conçue est compatible avec l'ancienne ET la nouvelle version du code, le temps de la bascule. Sans ça, le blue-green et le canary tombent : on ne bascule pas un routeur en moins d'une seconde si la base, elle, change de forme. Les auteurs renvoient à Refactoring Databases (Ambler et Sadalage) pour les patterns. C'est, en 2010 comme aujourd'hui, le vrai point dur de la livraison continue.