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.

Lire la suite →

Note : 4 ; De l’intégration continue à devops ! Des points de vue de grande valeur, mais bien trop verbeux. Jolt Award 2011 !

Ce livre fait en quelque sorte suite au « continuous intégration » publié dans la même série. Ici, l’orientation est résolument « devops », ou comment aller du développement à la mise en production. Aussi le livre ne s’articule pas seulement autour des problématiques techniques, mais aussi de processus et des activités garantissant la mise en production : tests unitaires, tests d’acceptance, gestion des releases, gestion des environnements, etc…

La première partie appelée « fondations » évoque tous les prérequis à la déliverie continue. On y parle de tests, de gestion de versions, etc… Bref de toutes sortes de choses que l’on connaît déjà et déjà détaillées par ailleurs. C’est un peu long et verbeux. On en prend pour 100 pages. Au premier chapitre on s’évertue de mettre en lumière la vue « ancienne » du release management. Pas si ancienne d’ailleurs, avec ses « RC1 », « RC2 », etc. On le fait à l’aide d’antipatterns un peu tarte à la crème, pour au final introduire les qualités attendues d’un bon pipeline d’intégration. Le chapitre 2, « configuration management » traite de deux sujets : la gestion de version, où les auteurs sont opiniated sur le développement en banche principale, et les informations de configuration qui doivent être externalisées. Les deux sujets seront repris plus tard. Ces prises de position, même si elles piquent un peu sont plus que sensées.

Une grosse trentaine de pages est consacrée à l’intégration continue. Pas de révolution ici, on reprend des principes désormais bien connus : un build court, ne jamais laisser un build cassé, raccourcir la boucle de feedback en lançant le build d’intégration au plus tôt. C’est un peu long pour dire des choses que l’on connait déjà et qui ne sont pas le cœur du livre. Je ne m’attendais pas nécessairement à voir évoquer la stratégie de test, mais c’est bien le sujet du chapitre 4 qui clôt la première partie sur une quinzaine de pages. Ce sont des pages bien dépensées cette fois, car les auteurs font le tour du sujet assez efficacement en suivant le framework de Brian Marrick. Cela dit, on est cette fois encore, un poil en marge du sujet.

Lire la suite →