Note : 5 ; De bonnes histoires et d’excellents principes mais un manque d’unité.

Le but inavoué de ce livre était d’être la référence sur le devops. J’en veux pour témoin l’impressionnante liste de noms à l’affiche. Les auteurs de « IT Rev » ont développé leur vision du Devops déjà ébauchée dans « The Phoenix Project », il s’agit des « 3 voies » dans la pure lignée de la pensée Lean. Ce livre est consacré au développement de cette idée.

Le livre lui-même est de format un peu plus réduit qu’à l’accoutumé, mais il atteint les 350 pages hors annexes (celles-ci en ajoutent 100 de plus), le volume de matière est donc conséquent. L’ensemble est découpé fin : on compte 23 chapitres rassemblés en 6 parties. La première d’entre-elle est consacré aux 3 voies. 4 chapitres sur 45 pages couvrent le sujet. L’introduction et le premier chapitre donnent les grandes lignes du devops, ce qui pourrait se résumer à la réduction du lead time.

Les 3 chapitres suivants de cette première partie sont chacun consacré à une des voies des fameuses 3 voies. Le second chapitre est ainsi consacré au « flow ». Sans surprise, on retrouve ici les principes du Lean appliqué au Kanban : taille des lots, élimination du gâchis, etc. Toutes choses permettant à la fois de réduire le temps de cycle et de donner de la fluidité au processus. Le second chapitre attaque le principe du feedback. Il est plus vague, évoquant le Andon et le déplacement de la qualité vers le développeur. Enfin le chapitre 4 nous parle d’amélioration continue, évoquant la culture « générative » au sens de Westrum. Les pratiques évoquées tournent autour de l’expérimentation et de la généralisation des découvertes locales.

La seconde partie attaque la grande question : par où commencer ? Il nous faudra pour cela près de 60 pages sur 4 chapitres. Le chapitre 5 nous invite à choisir notre première expérimentation au sein du SI : plutôt les « systems of engagement » aux cycles courts que les « systems of records » moins dynamiques. Mais surtout les « early adopters » de la courbe de Moore forment une première cible plus facile à adresser que les groupes plus conservateurs. Le chapitre 6 aborde la Value Stream Map et la nécessité d’un groupe dédié à la transformation mais sans étayer le sujet plus que cela. Dommage.

Le chapitre 7 confronte la structure des organisations (en silo ou orientées marché) à la loi de Conway. Si confronter l’optimisation du coût à l’optimisation de la performance a un sens, la finalité du propos, elle, n’est pas claire. Pour clore cette seconde partie, le chapitre 8 donne quelques clés très pratiques pour intégrer les ops au sein des équipes de développement. Rien de géant, mais au moins on répond à une question récurrente !

La 3ème partie va zoomer plus concrètement sur les pratiques du Flow, la 1ère des 3 voies. Ce sont 5 chapitres sur un peu plus de 80 pages qui occupent ce terrain. Le chapitre 9 traite de manière très condensée les fondations du « deployment pipeline ». J’aime bien l’aspect très pratique de la « check list » sur laquelle elles s’appuient. Un des take-away du livre. Le chapitre 10 est bien plus conséquent mais couvre un sujet plus conséquent encore : les tests automatisés. J’y trouve pas mal de choses déjà dites ailleurs, souvent de manière plus ou mieux développées. Le propos n’est pas mauvais, mais j’ai vu mieux.

Au chapitre 11 viennent les pratiques d’intégration continu (pour le développeur). C’est l’occasion d’évoquer les petits lots et le développement « trunk-based ». Peu d’explications sur le « comment » mais quelques témoignages pour nous inciter à emprunter cette direction. L’avant-dernier chapitre de cette partie nous invite à automatiser le déploiement mais en déconnectant le déploiement de la release, ce que les auteurs appellent le « déploiement self-service ».

Cette partie se referme sur quelques considérations architecturales pour éviter les grands sauts d’architecture toujours risqués. Bien sûr on pense architecture émergente, microservices et strangler-application.

La 4ème partie va très logiquement détailler les pratiques liées à la seconde voie, c’est-à-dire le feedback. Le sujet est développé au long de 75 pages formant 5 chapitres. Le chapitre 14 attaque d’emblée le monitoring : mettre en place une infrastructure lui étant dédiée et concevoir des métriques à tous niveaux (infrastructure, application, métier). Mais le texte insiste aussi sur l’intégration de ces tâches au sein des tâches quotidiennes. Le chapitre 15 est court et ambitieux : donner quelques clés pour analyser les problèmes rapportés par la télémétrie. On sent que les auteurs ont du background, mais le sujet est finalement trop ambitieux pour être traité correctement ici.

C’est de feedback pour déployer en toute sérénité qu’il est question au chapitre 16. On y traite de pas mal de sujets différents et c’est d’avantage source de confusion que de compréhension. Le chapitre

17 nous emmène vers l’hypothesis-driven développement et l’A/B testing. Le sujet est plutôt large, peut-être est-ce pourquoi ce chapitre traite plus de l’intention que du « comment » ? Cette 4ème partie se referme sur un chapitre consacré à la qualité de code, aux revues de code et au pair programming. Le sujet est traité un peu légèrement et n’avait pas, pour moi, de raisons de figurer dans le présent ouvrage.
La 5ème partie referme le tour des 3 voies en abordant l’apprentissage en continu. Ce sont seulement 3 chapitres sur une quarantaine de pages qui traitent du sujet. Pas mal de petites idées sont abordées dans le chapitre 19 pour « injecter de l’apprentissage dans le travail de tous les jours ». Si le post-mortem prends une belle place ici, c’est le chaos monkey qui attire le regard mais il n’est hélas abordé que sur une paire de pages.

Au chapitre 20, il est question de « convertir les découvertes locales en améliorations globales ». Le contenu n’est pas aussi géant que le titre le laisse paraitre. Mes take-away seront ici : la pratique du « mono-repo » et les communautés de pratiques. Les deux sujets ne sont hélas pas traités en profondeur. Cette courte partie se referme sur l’amélioration et l’apprentissage au niveau de l’organisation. J’ai envie d’ajouter l’étiquette « à faire » sur ce chapitre qui a sa raison d’être mais est malheureusement plus que légèrement traité.

La dernière partie est un peu fourre-tout, du moins de ce que les auteurs avaient envie de parler qui ne rentrait pas dans les autres parties. Cela commence avec le chapitre 22 et les pratiques liées à la sécurité. Le DevSecOps est assurément un sujet d’actualité, mais j’aurais préféré voir ici traité la manière d’intégrer les activités liées à la sécurité plutôt que d’essayer vainement de faire le tour du sujet. Enfin le dernier chapitre se situe dans la continuité car il parle de protéger le deployment pipeline.

Ce livre se voulait la bible du Devops. A cet égard, c’est raté. Certes on développe bien les « 3 voies », ce qui était l’intention d’origine, mais le propos manque de cohérence globale et ressemblerait plutôt aux « Balkans du devops » ! Le livre est émaillé d’histoires et de retours d’expérience, ce qui est toujours un plus. En conclusion un avis favorable mais mitigé.

Référence complète : The DevOps Handbook – Gene Kim, Jez Humble, Patrick Debois & John Willis – IT Revolution press 2016 – ISBN : 978 1 942788 00 3