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
Software Freethinker 
