Note : 3 ; Quand même un peu mieux que la Javadoc. Mais pas tellement plus…
Voilà un pavé à 800 pages qui fleure bon le livre de commande. Pourtant le périmètre de l’ouvrage est volontairement limité aux frameworks de base d’Eclipse : SWT et JFace. On ne parle pas de développer des plugins et encore moins une application RCP. Aucunement question de s’appuyer sur les points d’extension du Workbench ni autre plaisanterie du même acabit… Voyons comment on en arrive là.
Le livre est découpé en deux parties (trois en fait) de taille inégales :
La première partie « Getting Ready » couvre le setup de votre projet applicatif au bout de 2 chapitres. Cela dit, on ne s’étale pas et c’est bouclé en 25 pages en tout.
Dès la seconde partie, on passe aux choses sérieuses avec SWT. En fait, c’est le gros du bouquin : 10 chapitre sur un peu plus de 500 pages. Tout est abordé de façon logique et je dirais même classique. On se rend vite compte qu’il y a principalement 3 choses que noircissent la papier : de grosses copies d’écran, des listing de codes un peu trop extensifs et une reformulation de la javadoc ! C’est un peu dommage, car les explications qu’il y a entre sont plutôt claires.
Suite du compte rendu d’Agile France, après la journée de Jeudi disponible ici et ici.
De bon matin…
De bon matin, ce n’est pas moi. J’arrive à temps pour le café et discuter un peu avec les autres. Mais quand j’arrive, un petit groupe se livre déjà à des exercices de Qi Gong.
Je retrouve les autres dans la salle commune. On discute, Alex Tweet. Business as usual…
Assez plaisanté ! La journée va commencer, place à la keynote !
Coaching Teams Through Change
Rachel Davies nous avait déjà gratifié d’une session il y a peu lors du ScrumDay. Fort heureusement, ce ne fut pas la même. J’ai d’ailleurs préféré cette keynote.
Rachel travail pour Unruly, une société spécialisée dans le « social media advertising ». C’est un domaine où les spécifications changent véritablement tous les jours. L’objectif est ainsi de déployer effectivement tous les jours !
Le début d’un changement
Au début les départements produit et développement étaient deux directions séparées. C’est le départ du directeur produit qui a permit d’enclencher un changement de structure.
Ce changement, c’est l’organisation en équipes de 3 à 5 personnes pour développer le produit. Et pas seulement développer : ces équipes prennent en charge la totalité des activités entourant le développement : l’écriture des user stories, les tests, etc. Ce sont eux qui vont solliciter les différents interlocuteurs (produit, marketing, commercial) quand cela s’avère nécessaire. Pas de product Owner qui est la seule voix du client, l’équipe va parler directement à tous les interlocuteurs ! Parmi ces interlocuteurs, nombre d’entre-eux ne sont accéssibles qu’à distance : l’équipe utilise Google Hangout pour communiquer. La conversation s’engage avec les interlocuteurs pour trouver la plus petite chose utile à construire, ce qui nécessite de prendre en compte tous les point de vue.
Lone rangers et development owners
Tout le développement est réalisé en binômes. Mais les équipes sont constituées d’un nombre impair de personnes ! En fait, par rotation, l’une d’entre-elle est le « lone ranger ». Elles s’occupe de diverse choses dans l’équipe, mais pas du code de production. C’est aussi à cette personne que les intervenants extérieurs à l’équipe s’adressent, afin de ne pas perturber les binômes en train de travailler.
L’équipe a aussi développé l’idée de « owner of the development area » : un développeur plus expert au sein d’un sous-ensemble fonctionnel. C’est lui qui élabore une proposition par rapport à un besoin exprimé. Les propositions sont traitées en planning meeting. Celui-ci n’est pas un planning meeting classique XP : seule la priorisation des propositions y est traitée, il n’y a pas d’engagement de charge. Ces planning sont donc très courts : ils n’excèdent pas 30 minutes !
Gold card
A l’image de ce que Kniberg décrit pour Spotify, Unruly fait des efforts particuliers par rapport au bien être des équipes. Outre divers évènements sociaux, la société applique la politique du 20% free time inspirée de Google (bien qu’elle disparaisse progressivement de Google, justement). Ici elle s’appelle « gold card day » et sert de sources d’inspiration pour creuser de nouvelles idées.
Ce que j’en ai pensé
Sans être exceptionnelle, cette présentation nous offre l’opportunité d’avoir un retour sur une organisation d’équipe différente de ce que l’on voit aujourd’hui :
Les itérations s’estompent au profit de la déliverie continue, mais des points de priorités réguliers contrebalancent l’effet « court terme » du flux.
Pas de « product owner » ici : c’est l’équipe qui fait le lien avec les divers interlocuteurs. Le périmètre de responsabilité de l’équipe s’accroit, mais on évite ainsi l’effet paravent du PO !
Je change mon programme à la dernière minute. Je choisis en 15 secondes d’aller à une présentation résolument technique. Grand bien m’en a pris !
Le mythe du framework agile
Jean-Baptiste Dusseault vient mettre fin à quelques idées reçues concernant ces frameworks qui doivent nous agilifier / faciliter la vie. Au départ de ce « ras le bol » un titre de livre : Agile Web Developement with Rails ! Même co-écrit par l’un des signataires du manifeste agile (et par l’auteur de Rails), ll y a un problème ici. Probablement plusieurs même. Le premier est la taille du livre : près de 500 pages !
Le framework maison
Mais commençons par le commencement. Et le commencement, puisque nous parlons ici de frameworks « full stack », c’est le fameux framework d’entreprise. Un bon point : nous n’avons que trop rencontré ces pantalonnades. Lâchons-nous, ça va faire du bien !
Le but de ces frameworks, c’est d’avoir le « meilleur du moment », tout bien branché ensemble. On met les pantoufles, on débranche le cerveau, et l’on peut tranquillement produire plein d’applications en un tournemain ! Sauf que ça ne se passe pas comme ça. Ces braves frameworks transforment notre vie en enfer !
Citons dans le désordre :
Prévus pour être simples, ils s’avèrent en fait ultra-compliqués ! Peut-être leur conception et leur réalisation par des « équipes transverses » explique-t-elle quelque chose ?
Ils sont difficiles à tester et très bugués. Là encore, leur réalisation détachée des projets n’a pas contribué à leur testabilité. Utilisés uniquement par quelques projets de l’entreprise (au mieux) le « durcissement » du framework n’a jamais vraiment eu lieu…
pas de support : souvent les équipes ayant réalisé le framework sont parties depuis longtemps…
Qu’en est-il des « full stack » reconnus ?
Ici on parle des rails, Play, etc… Ils nous font la même promesse d’accélérer les développement du sol au plafond. En vérité, ils prennent des décisions d’architecture pour nous ! Jean-Baptiste va plus loin : en déléguant les choix d’architecture au framework, on laisse celui-ci nous utiliser !
Nous n’utilisons pas les frameworks “full stack” : ce sont eux qui nous utilisent.
Ce biais a des conséquences, on va le voir bientôt.
D’où vient leur succès ? Ils permettent de faire très vite 80% de l’application. Mais on galère sur les 20% restant ! Généralement, la réalisation en suivant le tutorial va vraiment vite.
Hélas, ils encouragent certains comportement. La partie « basse » entité et persistance est plus ou moins câblée. Il n’est pas possible d’y intervenir facilement. Et les entités ressemblent beaucoup aux tables de la base de données (ça rappelle les outils RAD client/serveur). On hérite donc d’un couplage vertical sur la base de données.
En fait, le seul endroit où l’on peut réellement raccrocher du code, c’est le contrôleur ! On l’accroche comme on peut. Et si des comportements communs apparaissent dans le code tartiné sur deux contrôleurs, le seul moyen efficace de le partager est le copié-coller ! Beurk !
Bref nous obtenons :
Des architectures monolithiques.
Des frameworks optimisés pour l’écriture de code … mais pas pour sa maintenance !
Des couplages forts avec la représentation et la base de données.
De grosses difficultés pour sortir des clous via des « plugins » et autres joyeusetés du genre qui ont de grosses courbes d’apprentissage.
Une testabilité rarement au rendez-vous.
Mais alors, c’est quoi un framework agile ?
Plutôt que de framework agile, parlons d’architecture agile, et des propriétés qu’elle devrait avoir.
Elle doit nous permettre de retarder les décisions
Elle minimise les couplages.
Elle est facile à changer.Elle est testable (via TDD et ATDD)
Une proposition et des inspirations
Pour Jean-Baptiste Dusseault, une telle architecture c’est :
Au centre un véritable modèle du domaine d’inspiration DDD, comme les proposent l’architecture hexagonale d’Alistair Cockburn ou la Clean Architecture de Bob Martin. Ce modèle ne dépend de rien et ne connait pas la persistence ni aucun système tiers, mais expose une API métier.
Une couche « commandes » implémentant les cas d’utilisation du modèle du domaine. Des idées que l’on retrouve dans la Lean Architecture de Jim Coplien.
Au-dessus un couche d’accès type CQRS dialoguant en asynchrone avec la couche commande et routant différemment les évènements commande (vers la couche commande) des requêtes qui sont adressées directement à la couche d’accès à la base de données.
Bien sûr le postulat de cette architecture, c’est que le métier est au centre des préoccupations. On n’évoque pas non plus l’architecture en micro-services qui me semble pourtant adaptée mais peut-être pas facile à concilier avec une architecture hexagonale…
La présentation de Jean-Baptiste est évidemment en HTML5 et elle est accessible en ligne ici.
Ce que j’en ai pensé
Cette session est une agréable surprise. Si le bashing des « frameworks agile » ne fait que confirmer ce que je pensais, les idées développées sur l’architecture agile me font beaucoup plus réfléchir, pour ne pas dire qu’elles soulèvent mon enthousiasme !
Comment j’ai développé mon muscle de l’amélioration continue en faisant mes courses
Ayant décidé de bouleverser mon programme, je n’ai de nouveau que 2 minutes pour changer mon programme. De nouveau, c’est une bonne pioche avec la session de Cyrille Deruelle !
Tout d’abord : pourquoi faire des exercices d’amélioration ? Pour que cela devienne une habitude, rendre cela naturel. Et Cyrille s’est livré à cet exercice en faisant ses courses du Samedi : c’est drôle et instructif !
Bien sûr tout ça n’a pas très bien marché du premier coup (d’où la nécessité de s’améliorer). Au départ, Cyrille a essayé d’impliquer son épouse (Product Owner des courses) dans la résolution des problèmes qu’il rencontrait. C’est une première leçon :
Les gens se foutent de la manière dont nous résolvons les problèmes.
Au hasard des améliorations, on va trouver :
« t’as rien oublié » … où comment suivre que l’on a tout acheté ? A l’aide d’une liste de courses et d’un gros feutre noir (le stylo fin ne convient pas).
Grouper les courses par catégorie : afin d’optimiser le parcours dans le magasin.
Prendre une photo des rayonnages pour les produits compliqués … afin de permettre à son épouse d’indiquer le produit souhaité. Le choix de la lessive a été vaincu ainsi !
Gérer les dates limites de consommation en les pré-calculant par rapport aux courses suivantes : afin d’éviter les erreurs pendant les courses.
Sortir des éléments du process : Les packs d’eau, c’est ingérable ! Alors on ne les sort du processus standard et on fait de temps en temps des ravitaillements en eau (en grande quantité) !
Les conclusions de Cyrille
Mes problèmes sont mes problèmes : Il n’est pas possible de s’en décharger sur d’autres personnes.
Il n’y a pas de choses simples : l’amélioration continue est une quête !
Les actions d’amélioration sont fragiles et difficiles ; c’est une discipline de tous les jours.
Mesurer l’impact d’un problème, c’est déjà 50% de la résolution
Enfin parfois, les améliorations ne sont pas possible, c’est le CCMCCC : C’est Con Mais C’est Comme Ca !
Grâce aux actions d’amélioration, Cyrille n’a pas seulement rendu son processus de meilleure qualité et plus efficace, il l’a aussi rendu fun !
Ce que j’en ai pensé
Une très bonne session : amusante et instructive. Bravo !
Refactorer du Legacy
Pas besoin de changer de salle pour la session de Johan Martisson. J’ai rencontré Johan lors du ScrumDay 2014. Ou plus exactement, Jean-Laurent de Morlhon me l’avait présenté. D’ailleurs Jean-Laurent était là à cette session résolument intimiste orientée craftmanship, avec des vrais morceaux de « live coding ».
Johan nous parle et nous démontre son approche de la reprise en main du code legacy, à l’aide de la librairie ApprovalTests. Pour résumer l’approche en quelques points :
On construit un harnais de tests résolument temporaires de manière rustique mais rapide.
On construit de manière assez brutale des combinaisons de conditions d’entrée pour couvrir une combinatoire de cas couvrant l’espace du problème.
On exécute une première fois les tests pour constituer la référence, sans se soucier de la justesse des résultats : il s’agit juste du comportement courant de la librairie.
On vérifie la stabilité du comportement du soft en comparant les résultats par rapport à la référence.
Au fur et à mesure du refactoring, on construit des tests unitaires définitifs. On peut envisager de se débarrasser définitivement des tests temporaires, de manière progressive.
Ce que j’en ai pensé
Au début de la présentation, je mes suis demandé où Johan essayait de nous emmener et j’ai pris conscience avec un peu de retard de l’efficacité et de la rapidité avec laquelle Johan mettait en place son harnais de tests ! Je dois dire que c’est très convainquant. Une petite vidéo pour vous en convaincre.
J’avais prévu d’être un peu plus long sur le descriptif de ce que Johan nous a montré avec l’outil, mais il le fait mieux que moi sur son blog. Je vous invite donc à le lire.
Pause déjeuner
Par une curieuse coïncidence, c’est de nouveau avec Jean-Luc Lambert que j’ai échangé lors de cette pause. Et nous avons parlé éducation et « génération Y ». Jean-Luc évoque avec enthousiasme le challenge que représente l’enseignement avec cette population.
Elle ne prend pas pour acquis les propos de l’enseignant. Le cours magistral a une vertu pour le moins limitée.
Ils sont « multi-tâches ». C’est assez déroutant, mais il faut faire avec !
Ils sont réceptifs aux jeux et aux exercices libres. Les techniques type « from the back of the room » leur sont bien adapté.
Ils ont beaucoup d’autonomie et sont entreprenant.
Ils ne se sentent pas beaucoup d’attache ni de fidélité pour la société pour laquelle ils travaillent.
Voilà pour cette dernière matinée. Je vous retrouve très bientôt pour la dernière partie de cet Agile France 2014 !
Note : 3 ; Ciblant l’analyste, un ouvrage trop superficiel et d’avantage focalisé sur le processus de réalisation que sur l’outil ! Dommage.
Difficile de faire autrement que de comparer ce livre à son pendant adressant OSWorkflow ! Même type d’ouvrage, même éditeur et même taille, l’auteur du premier est même relecteur du second. Bref, deux ouvrages courant dans la même catégorie ! Mais autant j’ai été accroché par le premier, autant j’ai été déçu par celui-là. Explications.
En réalité, dès le départ, on s’aperçoit que cela va être difficile : le premier chapitre n’évoque guère jBPM en guise d’introduction. On y évoque plutôt le processus d’analyse et de modélisation. Va pour les 20 premières pages.
Le second chapitre évoque de manière plus détaillée le processus de modélisation du BPM à l’aide d’une étude de cas ici introduite. Ce livre n’étant pas réellement un ouvrage de BPM, le traitement de ce sujet est quelque peu léger, sinon naïf. Et l’on est arrivé page 52 (sur 200) et toujours pas de jBPM à l’horizon.
On en parle enfin au chapitre 3, où tout le processus d’installation et de configuration est détaillé, un peu trop à la façon « pour les nuls » à mon goût. Mais on finit quand même par aborder le sujet qui m’intéresse ici en premier lieu, c’est-à-dire jPDL (on est quand même page 74). Au final nous avons quand même droit ici à 25 pages de matière réellement pertinente.
Le chapitre 4 évoque l’interface utilisateur, c’est-à-dire les formulaires JSP que l’on peut construire directement sur la plateforme jBPM.
Le chapitre 5 revient sur le leitmotiv des auteurs : le processus de développement. Nous avons toutefois droit à 7 pages particulièrement intéressantes sur l’intégration de systèmes : juste de quoi nous mettre l’eau à la bouche, mais clairement pas assez pour nous délivrer une information pertinente et utilisable !
Le chapitre 6 « proof of concept implémentation » noie pas mal d’informations importantes sous couvert de processus de développement (encore lui), mais sont toutefois évoqués : configuration, déploiement et même monitoring et BAM avec la plateforme SeeWhy. Ce dernier volet est tout à fait intéressant, à la fois par l’évocation de SeeWhy que par le fait que l’intégration en est bien décrite.
Le dernier chapitre sur le « process improvement » n’est que du bla-bla, oubliez-le.
Bref, ce livre est une grosse déception, je n’y aie trouvé que 50 à 60 pages d’informations utiles. D’un autre coté je n’ai pas ici une couverture complète du sujet me permettant de jauger si cet outil correspond à mes besoins. Je doute que vous-même y trouviez votre bonheur.
Référence complète : Business Process management with JBoss jBPM, a practical Guide for Business Analysts – Matt Cumberlidge – Packt publishing 2007 – EAN: 9 781847192 36 3
Note : 7 ; Un tour d’horizon clair concis et efficace
Est-il possible de faire un tour d’horizon introductif d’OSWorkflow en moins de 200 pages ? De toute évidence : oui, et cela sans faire particulièrement de concessions au sujet traité. Cet opuscule est en effet découpé en 8 chapitres, chacun focalisé sur une facette précise.
Le premier chapitre, comme il se doit traite de la vue d’ensemble d’une SOA animée par un moteur d’orchestration et de la vue de cette architecture par le WfMC. 20 pages suffisent à cela.
Le second chapitre nous donne déjà toutes les clés sur les capacités d’OSWorkflow en nous présentant les éléments les plus importants de la définition d’un workflow avec OSWorkflow et comment le tester !
A partir du chapitre 3, on rentre dans des aspects plus pointus : écrire du code Java qui s’interfacera avec le moteur de Workflow ! Les choses sont exposées simplement et progressivement, on n’est jamais perdu. Le chapitre 4 termine les aspects applicatifs généraux en évoquant l’intégration du moteur au sein d’une application.
C’est à partir du chapitre 5 que sont traités les aspects avancés. Ils ouvrent de nouvelles perspectives et sont rafraichissants sur ce point. Le chapitre 5 (justement) est un bon essai en ce sens, mais tout en donnant une bonne idée sur ce qu’est l’intégration d’un moteur de règles, il n’est guère convaincant. Et quitte à parler Open-Source, pourquoi ne pas avoir plutôt évoqué Jess ?
L’intégration de Quartz, évoquée au chapitre 6 est plus intéressante, car elle permet d’imaginer des architectures non seulement basées sur des workflows, mais également asynchrones . Là encore les exemples sont suffisamment simples et complets pour donner une bonne idée de la chose.
J’ai particulièrement apprécié le chapitre 7 et son traitement des CEP (complexe events processing) avec ESPER. C’est en fait la première fois que je vois évoqué concrètement la mise en œuvre de ce concept. Bravo !
Le chapitre 8 est un peu l’inattendu de cet ouvrage, puisqu’il ne traite rien de moins que le BAM ! L’implémentation est faite avec Pentaho BI (qui est plutôt une suite qu’un framework Open-Source), mais l’ensemble est convaincant.
Voici donc un opuscule qui remplit globalement ce que l’on attend de lui : un tour d’horizon du moteur de workflow, avec des exemples. Il vous sera incontestablement utile si vous souhaitez mettre en œuvre OSWorkflow, mais seulement au début, car il limite ses ambitions aux aspects introductifs, ce qui constitue le point faible du livre.
Référence complète : OSWorkflow, a guide for Java developers and architects to integrating open-source Business Process Management – Diego Adrian Naya Lazo – Packt Publusing 2007 – EAN : 978 1 847191 52 6
Note : 7 ; Du concret sur l’ESB, mais un texte qui accuse aussi son âge…
Pas facile de s’y retrouver au sein du concept technico-marketing qu’est l’ESB ! Ce dont on a surtout besoin, c’est du concret. Et c’est exactement ce que l’auteur nous propose ici. Malgré son titre généraliste, le livre se focalise presqu’exclusivement sur la mise en œuvre de l’ESB open-source d’Apache, ServiceMix et de la norme JBI qu’il dessert.
En fait, les 2 premiers chapitres sont consacrés à la vue générale des problématiques d’intégration. Le premier chapitre présente les banalités habituelles sur l’ESB (mais plutôt bien présentées) et le second se focalise sur l’aspect plus technique en introduisant JBI et les « integration patterns ». Ce n’est qu’au chapitre 3 (on est déjà page 57) que ServiceMix, ou plutôt la vue globale de son architecture, est introduit.
A partir du chapitre 4, on passe en revue les différents types de binding, selon une complexité croissante. Tout d’abord un binding simple, dit conventionnel (chapitre 4), puis un binding « contract last » avec XFire (chapitre 5). Un binding plus complexe à trois niveaux est abordé au chapitre 8, mettant en œuvre des EJB, tandis que le binding de POJO est enfin abordé au chapitre 9. Puis c’est le tour de l’approche « gateway » ou « contract first » avec Axis (chapitre 10).
Les chapitres 6 et 7 font figure d’interludes. Il était difficile d’aller bien loin sans aborder les concepts de packaging et de déploiement des services ServiceMix, c’est chose faite au chapitre 6. De même, il est parfois utile de compléter la panoplie de bindings proposés par l’ESB, c’est l’objet du chapitre 7.
La problématique du transport est aussi un domaine où l’ESB permet une certaine souplesse. Le chapitre 11 montre comment accéder un Web Service au travers de JMS. Au chapitre 12, on voit comment effectuer le binding entre Java et XML (le langage natif de l’ESB) en utilisant en autre XStream. Enfin le chapitre 13 aborde le point plus complexe mais aussi plus exotique des proxys JBI.
Les derniers chapitres peuvent être vus comme des aspects avancés, donc pas forcément indispensables de prime abord. Le chapitre 14 aborde la problématique de versioning des Web Services, utile dans le cadre d’un SI « évolutif ». Le très long chapitre 15 traduit en services ServiceMix de nombreux integration patterns. L’agrégation de services est abordée au chapitre 16. Il s’agit d’un sujet plutôt avancé et c’est tant mieux car le propos n’est pas des plus clairs. On finit en ordre dispersé par un chapitre fourre-tout, avec les transactions, la sécurité le clustering et la vie des bêtes au chapitre 17. J’espère qu’il y a mieux ailleurs car ce n’est pas la joie.
Comme on le voit, c’est un tour d’horizon plutôt complet qui nous est proposé sur 400 pages. Il s’adresse clairement aux architectes. On y aborde les concepts et le code. Si le code Java est clair, il est fort dommage (et c’est mon reproche principal) que les configurations ServiceMix pourtant complexes soient aussi peu décortiquées. Leur compréhension reste ardue.
Ce type d’ouvrage est hélas sujet à l’obsolescence. Ne nous voilons pas la face, c’est bien le cas ici. ServiceMix (pour ne parler que de lui) a déjà changé de version majeure depuis un moment. Il n’a plus nécessairement la pertinence qu’il avait au moment de sa sortie…
Référence complète : Service Oriented Java Business Integration – Binildas C. A. – Packt Publishing 2008 – EAN : 978 1 847194 40 4
Note : 7 ; Une qualité de prose qui fait honneur à la « in action » series, mais une lecture un peu lourde au total.
Mon premier contact avec ce livre a été teinté d’appréhension : il compte pas moins de 440 pages hors annexes, ce qui me semble beaucoup, je le dis sans ambage ! Puisque l’on en est aux présentations : le volume est découpé en 14 chapitres, eux mêmes regroupés en 3 parties. Il faut en plus compter une vingtaine de pages d’annexes. Cela nous donne une moyenne d’une trentaine de pages par chapitre. C’est beaucoup à mon gré, mais consistent avec le standard de la « in action » series. A propos de cette série, Manning fait beaucoup d’effort pour maintenir une ligne éditoriale de bonne qualité qui permet d’être rarement déçu avec chacun des opus. Nous verrons que ce volume fait honneur à la série.
La première partie s’intitule « background » et regroupe les deux premiers chapitres pour un total de 50 pages. Le premier d’entre eux nous fait faire le tour du propriétaire. Non seulement on y comprends l’architecture logique (finalement, Spring Batch c’est un framework-ETL Java) mais on va jusqu’à faire une mini-application de traitement (lecture, traitement et écriture) avec la configuration Spring correspondante. Impressionnant pour un premier chapitre !
Le second chapitre rentre plus avant dans les concepts sous-jacents du framework : job, métadonnées du job, step, etc… Le but de ce chapitre est de nous donner les clés pour décomposer une spécification de traitement en étapes décomposées. Bon boulot, à nouveau.
La seconde partie « core spring batch » est de loin la plus imposante du livre. Elle compte 7 chapitres et 225 pages. C’est donc un mini-livre à elle toute seule. C’est d’ailleurs à mon avis le problème le plus important du livre, mais je reviendrais là-dessus plus tard ! Le chapitre 3 qui débute cette seconde partie nous immerge dans la configuration des batches. Plus clairement : comment s’articule la configuration Spring d’une application Spring Batch. Il y a 5 niveaux d’entités hiérarchiquement emboitées à configurer (sans compter le repository de jobs) et le chapitre passe par le menu la manière de configurer tout cela avec les attributs qui vont bien. C’est un poil lourd, mais bien écrit.
Le chapitre 5 explore en profondeur la manière de lancer (et arrêter) les jobs : en ligne de commande ou en planifiant de différentes manières. Le tout est bien illustré par des diagrammes de séquence, entre autre chose.
Avec le chapitre 5, on attaque réellement le développement de traitements Spring Batch, en débutant par les composants de lecture. Le sujet est largement balayé en largeur sur 40 pages, que ce soit sur des fichiers plat, du JSON, du XML ou de l’accès aux bases de données. Rien à dire sur la manière dont le sujet est abordé, mais c’est quand même un peu long quand ce que l’on souhaiterait, c’est arriver au bout du chemin pour voir ce que cela donne !
Le chapitre 6 aborde fort logiquement le composant d’écriture. Si les aspects de base (field extraction, formatage) sont fort logiquement abordés, là aussi le sujet est abordé en largeur, avec non seulement l’écriture sur fichier, mais la production de XML, de file sets et l’écriture en base de données. Mais on aborde aussi l’écriture en flux JMS et l’envoi de mails. Là aussi je trouve que cela fait beaucoup pour une première passe, et paradoxalement, certains de ces sous-sujets sont traités un peu rapidement !
Toujours dans la même veine, le chapitre 7 nous présente les composants de traitement. Les items processors de Spring Batch recèlent nombre de richesses et il me semble difficile de faire des impasses par rapport à ce qui figure dans le texte. La lecture du chapitre me laisse cependant un léger sentiment de confusion, mais rien de bien grave. Les excellentes illustrations graphiques ou en code permettent de toute façon de se raccrocher aux branches.
Le chapitre 8 compte à peine 30 pages, mais elles recèlent une expertise qu’il serait dommage de rater. Il s’agit de la conception des reprises sur erreur avec Spring Batch. Excellent !
Cette seconde partie s’achève avec le chapitre 9 qui couvre l’aspect transactionnel des batches. Le sujet est traité de manière solide et claire en 25 pages, que ce soit sur les erreurs à ne pas commettre, sur la portée des transactions et les différents niveaux de transaction disponible (job, chunk,…). Rien à redire.
La 3ème partie du livre est consacré aux « sujets avancés » et le premier chapitre de cette partie, le chapitre 10, dédie 25 pages au contrôle d’exécution. Partage de contexte, flux alternatifs et même externalisation des définitions de job sont parmi les sujets traités.
Avec le chapitre 11, on commence à toucher du lourd, à savoir l’intégration d’entreprise. Les auteurs évoquent d’abord les styles d’intégration d’un point de vue architecture logique. Il n’est pas étonnant qu’ils fassent référence aux Enterprise Integration Patterns de Gregor Hope ! D’un point de vue pratique, la quarantaine de pages de ce chapitre s’appuie sur 2 fondations : Spring Integration d’une part et Spring MVC pour illustrer une intégration http/ReST. Il est juste dommage que les 2 approches ne soient pas mieux abordées en séquence afin de rendre la prose plus claire.
Ce livre ne rate pas le, oh combien important, sujet du monitoring. Le chapitre 12 fait du bon boulot là-dessus, que ce soit pour décrire la structure BDD supportant cela, pour décrire l’intégration JMX ou même pour éclairer l’usage de l’outillage prêt à l’emploi de Spring batch à savoir Spring Batch Admin ou JConsole.
Le chapitre 13 est vraiment un sujet avancé car il traite de scaling. Un chapitre sur lequel il est possible de faire l’impasse en première lecture.
Ce n’est pas le cas du dernier chapitre qui aborde la problématique des tests. Il le fait à 3 niveaux : tests unitaires, tests d’intégration et tests fonctionnels. Ces 3 niveau s’appuient sur JUnit est sur des helpers fournis par Spring batch. Je ne suis pas convaincu par ce qui est proposé du côté tests fonctionnels, mais les 2 autres niveaux sont OK.
Spring Batch in action est une bonne surprise. Les auteurs ont fait globalement un très bon travail à rendre le propos clair et l’apprentissage progressif. L bouquin reste hélas un gros pavé. Mais le framework est aussi beaucoup plus riche que je ne l’avais pensé au début. Pour en rendre l’abord plus digeste, je pense que les auteurs auraient dû découper la seconde partie en 2 : en traitant d’abord d’un cas d’utilisation simple n’utilisant qu’un sous-ensemble de chacun des 3 types de composants, puis une seconde itération pour les autres cas de figure. Au final, le volume du livre aurait un peu augmenté mais cela aurait permis au lecteur de faire l’impasse sur une centaine de page en première lecture !
Ce livre s’adosse à la version 2.1 de Spring batch, il est donc toujours parfaitement d’actualité, mais une révision sera certainement nécessaire quand la version 3.0 sera en GA.
Référence complète : Spring Batch in Action – Arnaud Cogoluègnes, Thierry Templier, Gary Gregory & Olivier Bazoud – Manning 2012 – ISBN : 978 1 935182 95 5
Note 5 : Un propos qui serait clair s’il n’était alourdi par la présentation de 2 ESBs et qui a prématurément vieilli.
Pour bien comprendre ce qu’est un ESB, le mieux reste encore de le mettre en pratique. C’est l’objet de ce livre : mettre en œuvre non pas un mais deux ESB et de comparer leurs cas d’utilisation. 11 chapitres sur 235 pages regroupées en 3 parties auxquelles il faut ajouter les 50 pages d’annexes sont nécessaires à ce défi.
La première partie est dévolue à la découverte du monde de l’intégration en général et de l’ESB en particulier. Le premier chapitre nous parle des cas d’utilisation des ESBs dans le monde des architectures J2EE. En fait, il va plus loin que cela en nous proposant un « hello world » avec chacun d’entre eux. C’est une bonne mise en jambe.
Après la présentation générale, vient l’architecture. Mule et ServiceMix (car c’est d’eux dont on parle) sont présentés du point de vue des concepts architecturaux, en empruntant largement les représentations officielles. Mais les auteurs montrent aussi les différents concepts en illustrant avec des fragments de code. Là aussi, c’est tout bon.
Présenter 2 ESBs présente aussi des difficultés. Ce chapitre 3 consacré à la mise en œuvre jongle entre les 2 plateformes. Cela rends la lecture compliquée et les 35 pages de ce chapitres semblent denses, sinon fouillis. Il eut été préférable de consacrer un chapitre à chacune des cibles.
Cette première partie se conclut par le chapitre 4 au cours duquel on va réaliser un mini-projet d’intégration avec Mule et avec ServiceMix. On y trouve aussi une évocation de Spring Intégration, encore balbutiant au moment de l’écriture de l’ouvrage mais qui soulève apparemment l’enthousiasme des auteurs.
La seconde partie est une plongée en profondeur dans les fonctionnalités des ESB. Il compte également 4 chapitres. On débute par le chapitre 5 où il est question de traitements sur les messages. On y évoque bien entendu le content-based routing, la validation et la transformation des messages. Le tout abondamment illustré de code avec en complément de Mule et surtout de ServiceMix : Apache Synapse et Camel.
Le chapitre 6 traite des connecteurs, de la manière dont ils s’intègrent et ils s’utilisent. On y passe en revue la connexion aux fichiers, à JMS, l’accès aux données via JDBC au mail, à JNDI ou au FTP. Chaque fois ServiceMix semble un peu mieux traité que son rival. Les 50 pages de ce chapitre ont un peu des allures de catalogue mais tout est clairement expliqué, illustré de schémas et de code, donc c’est O.K.
Le sujet peut paraître désuet aujourd’hui, pourtant il reste important : l’accès aux services Web SOAP est le thème du chapitre 7. Les deux plateformes s’appuient sur CXF aussi bien pour invoquer que pour être appelés. Le WSDL est déjà lui-même un peu touffu, il ne faut pas s’étonner que ce chapitre ne soit pas très simple d’accès. Last but not least, ce chapitre évoque aussi quelques normes WS telles que WS-Security ou WS-Adressing. Ca ne fait rien pour alléger le propos.
Cette seconde partie se conclut par un chapitre dévolu à la gestion d’erreurs et à la sécurisation des ESBs. C’est pratiquement un challenge d’y comprendre quelque chose. Mais c’est surement un sujet sur lequel on peut revenir plus tard, une fois que l’on s’est réellement approprié le sujet. Car les explications ne sont pas évidentes quand on débarque…
La 3ème partie est consacrée à des « case studies » qui s’avèrent en fait être un peu plus que des études de cas, mais des sujets avancés dans la mise en œuvre d’ESB. Le premier chapitre de cette dernière partie qui en compte 3 est consacrée aux Enterprise Integration Patterns de Gregor Hope. Après une courte introduction au sujet, on plonge dans la réalisation d’un système de réservation pour 3 restaurants en intégrant progressivement différents patterns des EIP. On passe ainsi du CBR au publish-subscribe tout en allant chercher des données en base… cela devient plutôt complexe surtout qu’il faut de surcroit faire cela sur 2 plateformes.
Je me demandais à quel moment on allait parler de monitoring. La réponse est : c’est au chapitre 10 ! On continue avec notre cas d’utilisation sur les restaurants et c’est aussi l’occasion d’aborder d’autres patterns comme le Message Store (c’est une base de données XML, eXist qui est utilisée ici). Comme on pouvait s’y attendre, on aborde aussi JMX. Là aussi devoir traiter 2 plateformes complique terriblement le propos. C’est d’ailleurs Mule qui tient la corde ici, il est mieux outillé pour gérer les instances de production. Pour ServiceMix, il faut en gros se tourner vers JConsole…
L’ouvrage se conclut sur le chapitre 11 et l’intégration d’un moteur de workflow ! Ca ne rigole plus et c’est même un peu trop pour le livre. Logiquement, c’est jBPM qui a été choisi. Mais on consacre aussi quelques pages à Apache ODE (qui semble aujourd’hui moribond). Je pense qu’on aurait pu faire l’économie de ce chapitre pour mieux traiter séparément les deux ESBs dans le reste du livre.
Les sujets abordés deviennent parfois ardus, mais le texte est globalement de bonne qualité et bien illustré. Comme je l’ai dit, il est rendu complexe par le traitement parallèle, je dirais presque schizophrénique de deux plateformes. Plus gênant, les exemples de code ne semblent pas fonctionner directement. Ils demandent au minimum un peu de bricolage. Trop pour que l’on s’amuse à tous les tester. Autre grand regret : la vitesse d’obsolescence. Le texte traite de ServiceMix 3.x au moment même ou ServiceMix (qui est très différent) apparaît. On en est aujourd’hui à la version 4.5.x ! Il en va de même pour Mule qui était en version 2.0 au moment de la rédaction et qui est aujourd’hui en 3.4 !
Pour ces raisons, je ne saurais conseiller ce texte aujourd’hui. Il mériterait une mise à jour, car les évolutions de ces deux ESBs sont maintenant en rythme de croisière, avec le travail de fond nécessaire sur les exemples. Malheureusement, je ne pense pas que cela arrivera…
Référence complète : Open Source ESBs in Action – Tijs Rademakers & Jos Dirksen – Manning 2009 – ISBN : 1933988215 ; EAN13: 9781933988214
Avec ses 500 pages, cet ouvrage ne cache pas ses ambitions de couvrir le sujet en profondeur. Il n’est découpé qu’en neuf chapitres, mais complétés d’annexes assez volumineuses couvrant les API sous forme de manuel de référence sur 70 pages.
Le chapitre 1 nous fait le tour du propriétaire sous l’angle de l’architecture. C’est ma fois fort réussie.
Au chapitre 2, on s’attaque au développement d’une extension d’Alfresco en utilisant Eclipse. Le but essentiel semble être de prendre de l’aisance sur l’environnement de travail. Toutefois j’ai trouvé la démarche un peu confuse.
Le chapitre 3 est particulièrement consistent, mais aussi très complet. Il aborde une facette différente d’Alfresco mais plus importante encore : la programmation de définition de contenus : création de nouveaux types, de propriétés, relations et facettes. Puis viennent les aspects qui viennent s’y greffer : programmation avec Java, les Web Services et PHP, customisation de l’IHM et des recherches, etc… Bref c’est particulièrement complet, mais le style rend tout cela hélas pas très facile à appréhender.
Le chapitre 4 fait suite assez logiquement, car il trait de tous les automatismes de traitement qui peuvent se greffer sur les contenus : actions, transformateurs, extracteurs, etc… Cela n’est en fait utile que si l’on a bien sûr l’intention de basculer de l’intelligence métier sur la gestion de contenu…
Le chapitre 5, moins utile de mon point de vue évoque la customisation de l’IHM d’Alfresco, donc utile seulement si l’on veut donner un accès à l’IHM du progiciel aux utilisateurs. J’avoue que je finis par être un peu noyé par ces fragments de code ou de XML que j’ai du mal à rattacher à quelque chose. C’était déjà un peu vrai dans les chapitres précédents, mais ça l’est plus encore ici.
Le chapitre 6 est particulièrement important, du moins à mes yeux : il évoque l’API Rest d’Alfresco. Hélas, le texte part du postulat de l’utilisation de cette API depuis des pages HTML, depuis du code JavaScript. De mon point de vue cela réduit nettement l’intérêt et la portée du chapitre.
Un large chapitre, le chapitre 7, est consacré aux « worflows avancés », donc ceux s’adossant à jBPM. Si les aspects en contact avec Alfresco présentent un peu d’intérêt (mais je cherche toujours comment lier un document à une instance de workflow, comme je le fais pour Documentum…), la description en profondeur de jBPM sort un peu du cadre de cet ouvrage à mon avis. D’ailleurs il y a des livres sur jBPM, même chez PACKT publishing !
Le chapitre 8 est assurément le plus volumineux de l’ouvrage, car ses 80 couvrent le Web Content Management. Le lien entre WCM et ECM (alors que c’est sans aucun doute l’un des intérêts d’Alfresco) ne m’apparaît pas clairement montré. Mais il faudrait que je mette mon nez de plus près dans ce chapitre pour m’en assurer.
Le dernier chapitre aborde la sécurité, aspect souvent complexe sur les systèmes d’ECM. Mais on fait bel et bien le tour de la question : authentification (essentiellement avec LDAP), SSO et permissions.
De manière générale, je dirais que l’ouvrage semble faire le tour de la question. Ou plus exactement, il aborde tous les sujets, même s’il nous laisse aller vers la documentation pour couvrir complètement en largeur tous les sujets. Si l’on avait voulu le faire, le livre aurait probablement fait 2000 pages ! Donc le parti pris était surement le bon. Il n’en reste pas moins que le traitement du sujet est assez aride, et comme je dis plus haut, un peu indigeste.
Enfin bon, le livre fait le boulot. Si vous développez avec Alfresco, ce sera sans aucun doute un plus de l’avoir près de vous.
Référence complète : Alfresco Developer Guide, Customizing Alfresco with actions, web scripts, web forms, workflows and more – Jeff Potts – Packt Publishing 2008 – ISBN : 978 1 847193 11 7
Note : 6 ; A la fois plus et moins complet que l’édition précédente.
Spring devient de plus en plus important … de plus en plus gros, même s’il se modularise. Je me demandais bien à quelle sauce on allait être mangé cette fois-ci ! L’édition précédente faisait 700 pages, celle-ci en fait … 380 ! En fait, non seulement cette édition se recentre sur les aspects essentiels du frameworks (certains thèmes ne sont donc plus traités), mais les aspects qui le sont toujours ont été revus et en fait la table des matière a changé de manière non anecdotique. Mon conseil : si vous avez la seconde édition, conservez-là !
Dans la première partie, les déclarations XML sont traitées plus légèrement à la faveur des annotations plus largement décrites, ainsi que du langage d’expression. De même la déclaration d’aspects est traité sur plus d’espace.
Ce qui était dans la précédente édition la seconde partie se retrouve désormais sur deux parties (la 2 et la 3). La plus importante différence réside sans doute dans le « client side Spring » qui a complètement disparu.
La première partie « Core Spring » regroupe 4 chapitre et compte 110 pages. Elle reprend les aspects qui ont fait le succès des éditions précédentes : une bonne introduction à ce qu’est Sprint (en y intégrant dès le début les annotation et les aspects) et un chapitre très solide sur le wiring qui inclut les namespaces de Spring et le langage d’expression SpEL. A cela s’ajoute un chapitre tout nouveau sur la prise en charge de l’injection de dépendances par annotations qui complète celui consacré aux aspects. Tout cela est très didactique et très bien épaulé par des exemples assez courts pour être parlants et de bons schémas.
La seconde partie « Spring Application Essentials » est longue de 140 pages en 5 chapitres. C’est le liens aux couches applicatives qui sont traitées ici. D’abord l’accès aux bases de données. Ce chapitre s’enrichit d’une partie consacrée à JPA, mais hélas les autres frameworks (à l’exception d’Hibernate) sont abandonnés ! Regrettable, spécialement pour iBatis / MyBatis. Une lacune que l’on va retrouver dans le chapitre suivant consacré aux transactions qui fait même l’impasse sur les transactions XA ! Les chapitres dédiés à Spring MVC et Spring Webflow sont repris de l’édition précédente et actualisés. Mais ne cherchez pas l’intégration avec JSP, JSF ou Struts : cela a complètement disparu. Il en va de même pour l’intégration EJB (bon, pour EJB2, j’aurais tendance à comprendre…). Enfin le chapitre consacré à la sécurité est toujours là, ni mieux ni moins bien que dans l’édition précédente.
La dernière partie est consacrée à l’intégration. Les exporters qui sont là depuis la version 1.0 peuvent passer pour de vieux trucs, mais ils sont bien pratiques et ils figurent toujours au menu de cette édition sans en réduire la voilure. Ouf ! Ne pas évoquer le support REST eut été une grosse lacune aujourd’hui : un chapitre complet lui est consacré. On retrouve aussi le support JMS, qui traite aussi de l’intégration ActiveMQ et Lingo. Le chapitre consacré à JMX est très court mais fait le boulot. Et finalement, le dernier chapitre regroupe l’intégration des trucs qui ne vont pas ailleurs. : l’externalisation de la configuration (cela aurait eu plus de sens dans la première partie), le wiring via JNDI, EJB (tiens si, finalement on en parle…), l’envoi d’emails et la planification de tâches. Sur ce dernier aspect on ne parle que du Scheduling natif Spring, mais pas de l’intégration Quartz qui est pourtant plus puissant ! Là encore, ne jetez pas votre édition précédente.
C’est vrai, Spring devient de plus en plus volumineux, mais il devient aussi modulaire car tout le monde n’a pas besoin de tout tout le temps. La ligne éditoriale du livre suit ce principe et un ouvrage de près de 700 pages qui aurait été en route pour en faire 900 se trouve réduit à en faire 380. La qualité de la rédaction est toujours là et les adaptations à Spring 3.0 sont réelles sans que cela soit pour autant des changements en profondeur à bien des égards. Le livre a été profondément restructuré au passage, et cela me paraît plus logique et mieux fait ainsi. Il faudra donc aussi compter désormais avec d’autres volumes pour compléter celui-ci : Spring batch in Action, Spring Integration in Action, etc…
Bref, ne vus dépêchez pas de jeter la seconde édition…
Référence complète : Spring in Action, 3rd édition – Craig Walls – Manning 2011 – ISBN : 978-1-935182-35-1
Sacha Labourey n’est pas un inconnu pour moi. Pour vous non plus peut-être. Soat nous poposait une rencontre avec cette figure marquante du monde Java à la veille de Devoxx France (je sais, ça fait déjà un bail …), je ne pouvais que sauter sur l’occasion.
Pour ceux qui l’ignoreraient, Sacha Labourey fut le CTO de JBoss après le départ de Marc Fleury, mais c’est en tant que fondateur et CEO de CloudBees qu’il se présentait à nous ce soir-là.
En fait de présentation, j’ai hélas rarement mis de photo aussi médiocre sur mon blog, mais c’est ainsi. La voilà.
CloudBees propose une plateforme pour héberger la totalité du cycle de vie d’une application Java sur le cloud. En l’occurrence, il s’agit du cloud d’Amazon, mais ils travaillent activement à rendre leur plateforme indépendante de l’infrastructure du géant de l’e-commerce afin de donner plus de flexibilité au client.
Hardware as a commodity
A la base, il y a la conviction que l’on se dirige vers une commoditifaction (est-ce vraiment un mot ?) du hardware. Sacha Labourey évoque le parallèle avec l’électricité : si à ses débuts, il fallait posséder son propre générateur et gérer les aléas de la régularité de l’alimentation, aujourd’hui nous nous sommes “débarassés” du problème chez des prestataires. Nous n’avons plus que des prises de courant nous délivrant un courant normalisé, le reste est l’affaire de ce prestataire.
Ce mouvement inéluctable : spécialisation -> standardisation -> régulation, Sacha Labourey le voit s’appliquer aujourd’hui à l’infrastructure.
Doit-on aujourd’hui encore s’occuper des machines, de les configurer, gérer les mises à jours système et même les “piles logicielles” ? Existe-t-il une valeur spécifique à se construire sa pile logicielle spécifique ? Si elle existe, elle doit être marginale (du moins dans la plupart des cas) et ne justifie pas les efforts et le détournement de focus de la problématique métier que l’on souhaite adresser.
C’est là la proposition de valeur de CloudBees : rendre l’infrastructure aussi facile à exploiter qu’une prise électrique !
Cloud vs cloud vs cloud
On peut rappeler rapidement les 3 types de cloud proposés, ils sont déjà très connus:
IaaS : Ce sont les briques de base de l’IT. On pense à Amazon EC2, Rackspace, …
SaaS : Des solutions logicielles standardisées prêtes à l’emploi. Salesforce est probablement le premier nom qui vient à l’esprit.
PaaS : Il s’adresse aux développeurs. L’objectif est de ne plus avoir à gérer les serveurs et les services standard fonctionnant dessus : serveur d’application, load balancing, etc..
Le focus est sur le “S” final : voir les facilités comme des services, disponibles sous forme d’API. Cette dématérialisation offre aussi un avantage fort : la possibilité de faire des essais (donc des erreurs) et de commencer petit. On peut ainsi itérer rapidement sans devoir attendre des mises à disposition de serveurs et des installations logicielles. Elles sont prêtes et peuvent être exploitées tout de suite. Et être abandonnées tout aussi rapidement (le serveur ne finit pas à la cave).
Pour Sacha Labourey, une architecture typique d’entreprise serait la suivante :
Au niveau back-office : les systèmes “legacy”, très stables, intégrant peu d’innovation.
Au niveau front : des applications pour mobile (par exemple) communiquant avec un back-end évoluant très rapidement au rythme des nouvelles fonctionnalités disponibles dans l’appli mobile. Cette partie est peu stable et est le siège de beaucoup d’innovations
Une communication front / back selon les protocoles mis à disposition par le back-office
Aujourd’hui la partie front / produit est subordonnée aux frictions entre développeurs et départements “opérations”. Les personnes en charge des opération privilégient la sureté de fonctionnement et renaclent le plus souvent à déployer des solutions logicielles qui n’ont pas été validées en interne, ou en tout cas ne satisfont pas des critères d’acceptabilité.
PaaS et innovation
Pour améliorer la capacité à mettre en ligne, la tendance actuelle est le “devops”, faire travailler ensemble développement et opération et outiller les opérations de déploiement afin de pouvoir pratiquer très souvent des déploiement automatisés. Je fais là un gros raccourcis et ne rends probablement pas justice à ce qu’il y a derrière devops, mais l’idée est là.
CloudBees revendique du “no ops” ! Plusieurs facteurs sont nécessaire pour permettre cela. On verra aussi que c’est un peu une simplification, l’IT ne disparait pas.
Standardiser les environnements : à l’image de l’électricité délivrée en voltage et fréquence constants, la standardisation des environnements est un facteur clé. Chez CloudBees, ces environnements standards sont les ClickStacks.
Travailler en SLA : pour pouvoir se passer d’ops, il ne faut pas avoir à se soucier de contingences d’infrastructure telles que stockage, clustering, etc… Il faut pouvoir signer un engagement de performance, à charge du prestataire de faire les mises en oeuvre d’infrastructure nécessaires pour garantir cet engagement.
Avec le SLA vient la question du support : une plateforme intégrant des sous-systèmes tiers peut être sujete à des dysfonctionnements (ou des mauvaises utilisation) de n’importe lesquels de ces composants. Il est logique que le support de service intègre complètement le support ou la délégation de support de ces composants.
Bien sûr, cela n’a de sens que si l’on est capable de mettre cela en oeuvre non seulement sur l’environnement de production, mais aussi sur les autres environnements utilisés dans le cycle de développement : environnements de développement, d’intégration, de stagging, etc… Le support du cycle de vie de l’application est donc l’étape suivante logique. L’intégration continue y joue un rôle clé.
Cycle de vie applicatif et gouvernance
C’est Jenkins qui est au centre du cycle de vie applicatif chez CloudBees. Il faut dire que Kohsuke Kawaguchi, la figure emblématique de ce projet open-source est un des leaders techniques de CloudBees !
Aujourd’hui, la partie faible me semble être toute la partie acceptance testing, AB testing etc… Mais c’est déjà le point faible de pas mal de projets. CloudBees propose quand même un environnement de stagging permettant de tester ses applications en conditions réelles : beescloud.com
Dans cette image que Sacha Labourey nous dresse, nous voyons une entreprise avec de nombreux projets, sur chacun d’eux les développeurs font des choix indépendants transformant le système d’information en gigantesque tour de Babel. Justement ce que l’IT cherche à éviter et lui vaut cette image d’épine dans le pied. Quel doit être le travail et la position du département IT, alors ?
C’est ce que Sacha Labourey appelle l’IT pragmatique : laisser faire, mais rester informés. Puis travailler en consolidation des différents projets ensuite (comment ? mystère …). De toute façon, si on bloque les projets trouveront le moyen de passer quand même !
Donc l’IT ne disparait pas, mais elle cesse de s’occuper d’infrastructure pour se concentrer sur les workflow de données, de services, etc… Elle reste le gardien du temple.
Tirer les leçons
Sacha Labourey a une vision très radicale non pas de l’IT de demain, mais de celle d’aujourd’hui :
Passer son IT sur le cloud inquiète toujours. Mais la peur ne peut pas être une stratégie ! Rester organisés à l’ancienne peut nous valoir de voir un département de 20 personnes se faire griller la politesse par “4 punks dans une cave” comme le dit Sacha !
Il faut profiter des gains compétitifs que représentent des services prêts à l’emploi.
Aujourd’hui, les investissements ne prenant pas en compte le cloud sont déjà de la création de dette ! Méditez là-dessus mes amis…
Ce que j’en vois
Sacha Labourey nous a bien secoué sur une vision du développement se passant dans le cloud, en rupture avec nos habitudes actuelles. Et il est très convainquant sur l’aspect des choses que nous n’avons plus à prendre en charge…
Pour aborder cette rupture, il faut permettre la montée en compétence progressive des équipes. Le ClickStart que propose CloudBees s’apparente surtout à des assistants logiciels. Il faut apprendre à travailler avec son usine logicielle dans le cloud. D’après notre orateur de la soirée, cela va vite. Mais quand même…
Accepter la standardisation : c’est une condition sine qua non.
On peut avoir un développement produit dans le cloud. Mais qu’en est-il de la communication front-back, si le back-office est dans les murs de l’entreprise ? C’est très probablement un point faible. A moins que le back-office soit lui-même dans le cloud, ce qui est la solution préconisée par Sacha Labourey. Un tel choix nous amène rapidement à des considération de vulnérabilité de notre entreprise, dont les avoir ont quitté les murs pour être localisés … à des endroits que nous ne savons même plus localiser ! Mais ne sommes-nous pas déjà, voir plus, vulnérables avec l’informatique chez nous ? Il y a eu pas mal d’échange avec Sacha Labourey sur ce sujet et j’avoue que ces arguments ne manquent pas de fondements. Je ne vais cependant pas les développer plus avant, cela m’emmènerai trop loin.
La présentation de ce soir-là avait un ciblage très managérial, j’ai un petit regret là-dessus, surtout que notre orateur est un expert de haut niveau. Mais ce point m’était connu à l’avance, je n’ai donc pas de regrets à avoir.
Si vous avez le courage de voir le contenu complet, la video a été mise en ligne par Soat.
Il vous faudra un peu de la persévérance, car la video dure 2h30 … et contrairement à ce que Sacha annonce au début, il oubliera de répéter les questions !
Il me reste à remercier Soat pour cette opportunité d’en savoir plus sur le développement sur le cloud en général et sur Cloudbees en particulier, avec l’un des grands noms du monde Java.
Software Freethinker 
