Note de lecture : Grokking Continuous Delivery, par Christie Wilsonci

Note : 7 ; Pour s’initier sérieusement au continuous delivery

Cette série « grokking », c’est un peu le « pour les nuls » de Manning. Et tout comme cette série, ce n’est pas nul du tout. L’ouvrage rentre en profondeur dans le sujet, avec simplicité et pragmatisme, mais certainement pas avec simplisme. Comme nous le verrons, il s’avère même étonnant, en plus d’être abondamment illustré. Cela nous explique les 360 pages de cet ouvrage (hors annexes). Aussi, si la lecture est aisée, elle demande quand même un certain temps !

Le livre, justement, parlons-en. Il est structuré en 4 parties pour un total de 13 chapitres. La première d’entre-elles est une introduction sur 2 chapitres et un peu plus de 30 pages. Comme on peut s’y attendre, le premier chapitre est purement introductif, définissant le concept et ses concepts adjacents et lui donnant une perspective historique. C’est en fait une bonne idée, tellement il peut y avoir de subtilité entre les concepts et le texte ne fait pas l’impasse dessus. Il est précis et concret. C’est un bon chapitre. Le second chapitre s’inscrit en parfaite continuité pour décrire un pipeline de base en s’appuyant sur un cas d’étude, en l’occurrence des photos de chat. L’auteur nous prends par la main pour construire progressivement ce qui est un pipeline CI, finalement loin d’être basique. Tout ce fait progressivement en expliquant les concepts tels que guichet et transformation, progressivement. Seules les notifications par Webhook sont un peu spécifiques dans le paysage.

La partie 2 couvre les mises en œuvre nécessaires pour conserver un logiciel dans un état délivrable tout le temps. Elle pèse 5 chapitres sur 140 pages. Le chapitre 3 adresse la gestion de version et la startup de Sacha et Sarah va nous aider à y voir plus clair. Le texte fait le choix d’utiliser Github comme exemple. Il en fallait bien un, et il parait raisonnable. Cela permet de se familiariser avec les concepts de push et pull request. Le texte ne s’arrête pas là, il fait la transition avec le pipeline, et pourquoi pas dans le cloud ? Il adresse aussi la gestion de configuration en gestion de version en imaginant la connexion à une base de données également dans le cloud. Les auteurs vont plus loin que la gestion de version sensu-stricto. C’est un choix de l’auteure que nous retrouverons régulièrement.

Christie Wilson est amateure de Lint, de Pylint pour être précis. C’est un peu inattendu et le chapitre 4 lui est entièrement consacré. Encore une fois, le sujet est bien développé, considérons cela comme un bonus, même s’il ressemble à une parenthèse par rapport au pipeline. Au chapitre 5 nous attaquons un sujet crucial : les tests automatiques. L’auteure nous propose un angle intéressant : l’élimination du « bruit » pour mieux voir le « signal » ! Le chapitre est uniquement consacré à cela. En prime nous avons droit à une petite croisade « anti-retry » sur laquelle je suis complètement Christie Wilson !

Le chapitre 6 est toujours focalisé sur les tests, sur un aspect important pour leur intégration dans le pipeline : les tests lents. Il y a pour moi deux fails dans ce chapitre : l’utilisation de la pyramide de test comme boussole et le focus sur la couverture de tests, qui ne fournit pas le bon indicateur. Mis à part ce deux réserves non-négligeables, le chapitre nous donne d’excellentes clé, notamment sur le sharding à des fins de parallélisation, rarement évoqué, et sur le FUD (fear, uncertainty and doubt) concernant le patrimoine de tests.

Le titre un peu mystérieux du chapitre 7 « le bon signal au bon moment cache ce qui est mon chapitre préféré du livre ! Le cœur du propos est : à quel moment (et quel endroit) déclencher la CI. L’ouvrage développe un bon nombre d’options qui sont autant de stratégies pour exécuter périodiquement, sur la banche de feature avant le merge ou sur le master après le merge, etc. C’est sans doute la première fois que je vois cette question ainsi et aussi bien développée.

La 3ème partie s’intitule « rendre la livraison facile ». Elle est forte de 3 chapitres sur 90 pages. Elle s’ouvre sur un retour sur la gestion de version au chapitre 8, mais cette fois plutôt pour parler de stratégie. Le propos s’inspire beaucoup de Accelerate de Nicole Forsgren, mais avec une prose plus digeste. Comme on peut s’y attendre, l’auteure nous emmène vers le Trunk-based development, avec un certain pragmatisme. Ma frustration est l’absence d’évocation du feature toggling. C’est franchement un gros manque. Cependant, le texte a une position assez permissive envers le code mort qui m’a un peu étonné !

Le chapitre 9 évoque la sécurisation du build, sujet qui touche donc d’assez près la cybersécurité. Les niveaux de maturité SLSA sont évoqué mais très peu développés hélas. Le texte aura attendu ce chapitre pour évoquer le build répétable, donc l’outillage de CI/CD. Ici le choix retenu est de s’appuyer sur les Actions Github. Il s’avère d’ailleurs qu’elles ont un bon niveau SLSA. Les environnements éphémères et la conteneurisation n’ont pas droit à beaucoup de place et c’est dommage. La sécurisation des outils de build eux-mêmes n’est par contre pas du tout évoquée et c’est dommage. Ne l’est pas non plus la traçabilité des builds avec Grafea et in-toto, mais ce sont sans doute des sujets avancés par rapport au focus de l’ouvrage ? Déployer avec confiance est le sujet du chapitre 10. Une fois encore, il fait la part belle aux métriques DORA et nous gratifie d’un aperçu des stratégies de déploiement comme le rolling update (en évoquant l’épineuse question du rollback), le blue-green et le canary. Le texte garde une position plutôt timide sur le Q&A en aval, alors même que cette logique casse le flux et donc les métriques DORA !

Nous arrivons à la dernière partie : la conception du continuous delivery. Elle compte 3 chapitres sur 90 pages. Le chapitre 11 « from zero to CD » synthétise tout ce que nous avons vu jusqu’à présente. D’abord littéralement en réintroduisant les concepts en version accélérée pour nous rafraichir la mémoire, puis dans une mise en place progressive sur un projet page blanche. L’auteur nous propose ainsi sa propre vision de l’ordre dans lequel nous devons introduire les différentes étapes de build. Pour conclure ce chapitre, on attaque un sujet plus complexe : la mise en place sur un projet existant. L’exercice a le mérite d’exister, car il n’est pas si souvent évoqué, mais il me laisse sur ma faim et ne me convainc que modérément.

Au chapitre 12 « Scripts are code, too » j’imagine que l’on va parler du versionning, voir même de la mise en pipeline des scripts de la chine CI/CD. C’est bien évoqué succinctement sur les deux dernières pages du chapitre, mais en réalité c’est du versionning de scripts bash dont il est question. Finalement, je trouve ce chapitre fort peu utile. Pour terminer, le chapitre 13 va développer la conception de pipelines. Le propos est très progressif, partant de pipelines simples mais permettant d’évoquer la gestion des erreurs vers des versions plus complexes intégrant la parallélisation et le sharding. Cela aurait été un bon tremplin pour s’aventurer vers un pipeline event-driven, mais non. Github Actions permet cela mais le sujet est peut-être un peu trop aventureux ? Il évoque quand même du bout des lèvres le multi-pipelines, qui aurait sans doute mérité 4 ou 5 pages supplémentaires. Cela reste un très bon chapitre, qui conclut parfaitement l’ouvrage.

Sans hésitation, il s’agit d’un très bon livre. L’auteure introduit les concepts de manière très progressive, bien illustré en images et en exemples chaque fois. Ce serait un livre que j’aimerais conseiller à de nombreux développeurs (presque tous en fait) pour bien s’approprier les concepts ainsi que les tenants et les aboutissants du continuous delivery, car le texte fait vraiment un excellent travail pour cela. Malheureusement, je sais aussi que le volume de l’ouvrage rebutera ce même public qui n’est pas prêt à y investir le temps nécessaire.

Référence complète : Grokking Continuous Delivery – Christie Wilson – Manning 2022 – ISBN : 978 1 61729 825 7

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur la façon dont les données de vos commentaires sont traitées.