Une introduction aux principes de la livraison continue et comment celle-ci s’inscrit dans les principes du Lean Startup
Étiquette : devops
Treat servers like cattle, not pets
Rolf Russell via Eric Le Merdy sur Fréquence Valtech
Note de lecture : Continuous Integration, par Paul M. Duvall
Note : 3 ; Trop creux !
J’attends incontestablement de la « signature series » d’Addison Wesley qu’elle ne comprenne que des ouvrages de référence. Ce n’est pas le cas ici. Certes, le livre effectue un bon travail pour introduire et convaincre les nouveaux venus des vertus de l’intégration continue, en édictant les principes de base (que j’estime pour ma part connus) et en hésitant pas à les répéter (ce qui est parfois nécessaire).
Cet aspect introductif est en fait l’objet de la première partie, longue de 100 pages. Bien qu’à mon avis la cible de ce type d’ouvrage ne soit pas d’introduire le sujet, mais une expertise sur la mise en pratique, je n’ai rien contre une petite introduction. Mais 20 pages auraient suffi, surtout si l’on considère la teneur. En fait, on y trouve un peu trop de propos de haut niveau, qui me rappellent certains des moins bons volumes de « l’Object Technology series » du même éditeur. Bref, j’arrive à la fin de cette partie, non seulement sans avoir rien appris, mais avec l’impression que j’en sais plus que les auteurs.
La seconde partie est dédiée au traitement en profondeur de l’intégration continue. Le découpage en chapitres est plutôt pertinent : intégration continue des bases de données, tests, inspection, déploiement et feedback. Hélas le traitement des différentes parties manque carrément de profondeur. Les auteurs abordent bien le « ce qu’il faut faire » mais assez peu le « comment faire », hormis quelques exemples de scriptes Ant. À noter, en passant, que la quasi-totalité de l’ouvrage est basée sur le postulat de l’utilisation de Ant et Cruise Control (et de leur équivalent .NET), je suis donc frustré (avec bien d’autres, certainement), moi qui utilise Maven et Hudson (ce dernier outil n’est même pas évoqué dans la liste des outils en annexe, peut-être parce qu’il aspire trop d’utilisateurs de Cruise Control ?).
Bref, on est non seulement déçu par l’absence de recettes concrètes, mais aussi par l’étroitesse des typologies de projets abordés. Je suis déçu également par le discours : n’y a-t-il donc qu’une seule façon d’appréhender l’intégration continue ? Les auteurs posent pourtant de nombreuses questions pertinentes qui sont autant d’obstacles à la mise en œuvre de l’IC, mais leur seule façon d’y répondre est l’objection. L’expérience nous montre pourtant que l’IC est quelque chose de facile à casser, jamais ce point n’est abordé. Les vraies questions sur la complexité de mise en œuvre de l’IC ne sont jamais évoquées : Commit en deux temps pour les IC cassant trop souvent, cadre technologiques ancien ou hétérogène, équipes nombreuse, build long ou tests volumineux.
Les auteurs se réfèrent souvent à deux textes : le livre de Brad Appleton sur les patterns de gestion de configuration et l’article de Martin Fowler sur l’IC. J’aurais aimé que ce texte ait la profondeur et la pertinence du « Patterns on Configuration Management ». Pour ce qui est de se référer à l’article de Martin Fowler, j’attends simplement mieux d’un livre de 220 pages que de se comparer à un article qui en compte une dizaine.
Donc, grosse déception. Passez votre chemin.
Référence complète : Continuous Integration, Improving software quality and reducing risk – Paul M. Duvall, with Steve Matyas & Andrew Glover – Addison Wesley / Signature series 2007 – ISBN : 0-321-336338-0 ; EAN : 978 0 321 33638 5
Note de lecture : Release It ! Par Michael T. Nygard
Note : 9 ; Comprendre enfin les impératifs de production sur l’architecture. Book of the year 2007 !
Pour être tout à fait honnête, je dois avouer que j’ai d’abord acheté ce livre d’avantage par confiance envers l’éditeur (Pragmatic Programmers) que pour le titre, qui ne me disait pas grand-chose. Bien m’en a pris, le livre s’est avéré une mine de connaissances.
Ce livre traite de l’architecture des applications d’entreprise. Mais plutôt que de se focaliser sur les qualités classiquement attendues de telles applications, l’auteur s’intéresse aux comportements de applications d’entreprise en production. Et il connaît particulièrement bien son sujet, ayant participé aux mises en production de très gros sites de e-commerce. De fait, le texte regorge « d’histoires horrifiques » arrivés en production.
J’ai conscience que mon appréhension des besoins des équipes de productions par rapport aux systèmes que je développe est superficielle. Nous sommes dans deux mondes séparés. Cet ouvrage vient confirmer ce pressentiment. Jusqu’à présent, je pensais que la meilleure chose que j’avais à faire par rapport à la production était de produire un système solide et stable (de bonnes considérations), et que la seconde meilleure chose à faire était de produire un système très, très solide (ce qui commence à devenir stupide). L’auteur nous assène une vérité : tous les systèmes, d’une manière ou d’une autre peuvent et vont finir par faillir. Le design des applications doit êtres orientés par rapport à cette vérité, en termes de stabilité et en termes de capacité et surtout en terme de reprise sur crash !
Les 334 pages du livre sont découpées en 4 parties formant 18 chapitres. Il regorge littéralement de conseils d’architecture et de design formulés sous forme de patterns et d’antipatterns. Une vraie mine d’or !
Je recommande cet ouvrage sans aucune réserve. L’auteur prend des positions importantes et intéressantes, éclairées par une d’incontestables compétence et connaissances. Il nous fait découvrir un nouveau point de vue et de nouvelles idées à intégrer dans nos designs et nos architectures.
Référence complète : Release It ! Design and deploy production-ready software – Michael T. Nygard – Pragmatic Bookshelf 2007 – ISBN : 0-9787392-1-3 ; EAN : 978 0 9787392 1 8
Software Freethinker 
