Question de définition

Avant tout, j’ai choisi d’employer l’appellation « usine de développement » (ou « usine logicielle ») car elle correspond bien à l’idée d’industrialisation. Malheureusement, chacun met un peu ce qu’il veut derrière ce nom générique. Pour rajouter à la confusion, les termes de « forge » et d’« ALM » désignent des notions qui s’apparentent fort à ce qu’on peut attendre d’une usine logicielle. Avant donc de se lancer dans une étude, il est important de préciser sur quoi elle porte : sans prétendre être une définition de référence, c’est la définition suivante qui a servi de repère pour la présente étude.

L’idée de départ étant d’appliquer l’image de l’industrie « matérielle » au monde du développement logiciel, récapitulons les éléments de l’analogie que j’avais exposée dans mon article précédent pour citer les domaines couverts par notre usine :

• pilotage : recueil des demandes (exigences sur le produit), planification des travaux et suivi des activités,
• approvisionnement : fourniture de la matière première (ou des pièces détachées), à savoir le code source et les composants techniques,
• fabrication : chaîne de production proprement dite qui transforme la matière première en produits (construction des exécutables à partir de la compilation du code source),
• contrôle qualité : tests du bon fonctionnement des produits et de leur respect des critères de qualité,
• distribution : diffusion des produits auprès des clients (logistique de livraison / réseaux de distribution),
• support : réponse aux questions des utilisateurs (internes ou externes), gestion des anomalies et actions correctives.

On le constate d’emblée, une telle analogie considère l’usine au sens large et va bien au delà de la chaîne de montage. Cette vision correspond plutôt à celle du « supply chain management » qui s’intéresse autant aux flux et à leur synchronisation qu’au seul process de fabrication. En résumé, il s’agit de définir un cadre au sein duquel clients, fabriquant et fournisseurs se retrouvent autour d’un ou plusieurs produits. On est donc loin de la simple procédure de build !

A partir de là, rien n’empêche d’utiliser les appellations « forge » ou « ALM », pour peu que l’on garde en tête les six domaines que nous venons de citer. Nous verrons toutefois qu’on est souvent loin du compte, les « forges » ayant tendance à se limiter au gestionnaire de source habillé d’un bug tracker et les solutions d’ « ALM » étant très focalisées sur les fonctions de pilotage au point de négliger celles de construction.

Critères de l’étude

Même si les six domaines définis ne sont pas forcément d’égale importance, ils constituent donc un point de départ pour évaluer des solutions candidates au titre d’« usine de développement ». Néanmoins, comme peu de produits sont organisés selon cette vision et qu’il convient de rentrer dans le concret, nous nous sommes intéressés à des fonctions d’une granularité plus fine pour favoriser une analyse systématique.

Voici donc une description des fonctions et caractéristiques que nous avons étudiées :

Fonction	Description
Généralités & administration
Intégration des outils (portail)	Niveau d’intégration des différents outils constituant l’usine de développement
Facilité d’installation	Efforts et compétences nécessaires pour l’installation
Arborescence de projets	Le produit sait-il gérer des projets organisés en sous-projets ?
Création transverse de nouveaux projets	La création de projet se fait-elle en une seule opération concernant tous les outils ?
Templates de projet	Dispose-t-on de modèles de projets réutilisables ?
Gestion des utilisateurs et de leurs droits	La gestion des utilisateurs et des habilitations est-elle suffisamment aboutie et intégrée ?
Notifications par mail	Existe-t-il un système de notification par mail ? Est-il paramétrable ?
Fonction de recherche générale	Existe-t-il une fonction de recherche généralisée ? Est-elle efficace ?
Documentation	Quel est la qualité de la documentation ? Comment couvre-t-elle l’usine de développement dans son ensemble ?
Multilinguisme	Le produit est-il multilingue ?
Travail collaboratif
Trackers personnalisables	Quel est le niveau de fonctionnalité des trackers ? Sont-ils suffisamment paramétrables ?
Tâches arborescentes (sous-tâches)	Le produit propose-t-il le découpage de tâches en sous-tâches ?
Gestion des références	Le produit gère-t-il des liens entre les éléments des trackers ? Les liens entre projets sont-ils supportés ?
Forums	Est-il possible de créer et utiliser des forums ?
Wiki	Y a-t-il des fonctions de wiki ou de documentation collaborative au sens large ?
Messagerie instantanée	Trouve-t-on des fonctions de messagerie instantanée ?
Gestion de projet
Définition de roadmap	Peut-on définir et consulter une roadmap ?
Fonctions de planification	Quel est le niveau des fonctions de planification ?
Gestion de la disponibilité des ressources	Le produit gère-t-il les ressources (équipes) et leur disponibilité (calendrier) ?
Suivi d’avancement	Est-il possible et facile de suivre l’avancement des travaux ?
Vues graphiques	Le produit génère-t-il des vues graphiques ?
Calendrier	Le produit inclut-il une gestion de calendrier ?
Support de Scrum	Le produit est-il adapté à une conduite agile des projets (avec Scrum notamment) ?
Production de rapports (personnalisables)	Est-il possible de produire des rapports personnalisés (paramétrés par l’utilisateur) ?
Référentiels
Référentiel de bibliothèques	Le produit intègre-t-il un référentiel de bibliothèques (tel que Nexus ou Archiva) ?
Référentiel de code SVN	Le produit intègre-t-il le référentiel de code source Subversion ?
Référentiel de code (autres solutions, i.e. GIT)	Le produit intègre-t-il un autre système de référentiel de code source (tel que Git) ?
Navigation dans le référentiel en mode web	Y a-t-il une interface web pour accéder au contenu du référentiel de sources ?
Intégration continue
Intégration de Maven	Maven est-il pris en compte voire intégré ?
Pilotage des builds	Y a-t-il moyen de piloter les builds (via une console d’intégration continue) ?
Contrôle qualité
Tests unitaires	Le produit prend-t-il en compte l’exécution de tests unitaires ?
Tests automatisés d’IHM	Une solution pour les tests automatisés des IHM est-elle proposée ?
Tests d’intégration/montée en charge	Des solutions pour les tests d’intégration et/ou de montée en charge sont-elles proposées ?
Audit de code	Le produit comprend-il des fonctions d’audit de code (qualimétrie) ?
Publication
Repository Maven	Le produit propose-t-il la publication dans un référentiel de composants ?
Dépôt de fichiers	Existe-t-il une zone de dépôt de fichiers organisée ?
Espace documentaire	Trouve-t-on un espace documentaire où classer des documents (par sujets et par versions) ?
Section blog / news	Existe-t-il une section de type blog pour notamment communiquer des actualités ?
Modes d’utilisation
En installation autonome	Le produit peut-il être installé librement en mode « standalone »?
En mode infogéré	Le produit est-il proposé avec un service d’infogérance ?
En SAAS	Le produit est-il accessible en mode SAAS (rien à installer) ?
Types de projets	Quelles technologies sont supportées pour les développements ?
Ouverture / extensions / adaptations	Le produit peut-il cohabiter avec d’autres outils ? Est-il possible de l’adapter, le compléter ?

Une pondération a été précisée pour relativiser l’importance de certains critères par rapport à d’autres. Évidemment, la définition de ces critères est toujours discutable, surtout qu’elle dépend des contextes d’usages, mais c’est le lot de toute étude de reposer sur ce genre de choix.

Ces critères ont donc été évalués sur chacune des solutions, à partir de la documentation officielle et de tests des fonctionnalités sur le produit en action. Une note de 0 à 5 a été attribuée selon que l’on a constaté que la fonction était :

• inexistante (0)
• embryonnaire ou peu utilisable (1)
• partiellement implémentée (2)
• opérationnelle pour les cas courants mais avec certaines lacunes (3)
• aboutie et efficace (4)
• particulièrement bien faite, avec des options complémentaires intéressantes (5)

FusionForge

Le premier produit a avoir été étudié est FusionForge, qui est un successeur de GForge, lui-même héritier du fameux SourceForge. C’est un produit open source écrit en PHP.

Le diagramme suivant résume les notations issues de l’étude pour les pans fonctionnels définis :

Sans grande surprise, si FusionForge propose une couverture correcte des fonctions d’une forge traditionnelle, il ignore les aspects construction, intégration continue, contrôle qualité. Un travail spécifique est donc nécessaire pour le compléter. En contrepartie, il a l’avantage de rester générique, ouvert à toute nature de projets. C’est un produit qui convient bien pour des usages assez peu ambitieux ou des contextes où les compétences et les budgets permettent la construction d’une usine de développement « maison ». L’étude lui attribue la note moyenne de 2,2 sur 5.

Redmine

Redmine est un concurrent direct de FusionForge. C’est une forge open source basée sur les technologies Ruby.

Redmine obtient une note moyenne de 2,5 et souffre globalement des mêmes lacunes que FusionForge puisqu’en l’occurrence, ce n’est pas une usine de développement telle que nous l’avons définie. En tant que forge, c’est une solution de qualité, portée par un projet open source actif et réputé mais il y a des efforts à faire pour la transformer en usine logicielle.

Tuleap

Tuleap est un produit qui se définit comme une suite d’ALM open source, elle-même issue de la forge Codendi et portée par une société française dédiée. En conséquence, la couverture fonctionnelle est plus complète, plus aboutie et la note moyenne atteint la valeur de 3 :

L’étude révèle que le produit comporte des fonctions évoluées autour des trackers, avec de bonnes possibilités de personnalisation, du reporting de qualité ainsi qu’un bon support des méthodes agiles. Malgré cela, les fonctions d’intégration continue y font figure de parent pauvre : Jenkins est inclus mais on doit se débrouiller pour l’utiliser et le compléter notamment avec des outils de contrôle qualité et un référentiel de composants. Au bilan, Tuleap est un bon candidat pour l’usine de développement mais demande quelques efforts complémentaires pour couvrir le périmètre.

IBM Rational Collaborative Lifecycle Management

L’étude s’est ensuite attachée à évaluer une suite d’ALM de référence, à savoir celle d’IBM. La suite en question s’organise autour de la solution nommée « Team Concert », elle-même reposant sur « Jazz », une plate-forme implémentant le standard OSLC pour l’ALM.

On pourrait s’attendre à ce que ce produit d’un autre niveau remplisse haut la main les critères de notre étude mais il n’obtient que la note globale de 3 et montre de grandes disparités dans la couverture fonctionnelle :

On constate que si le produit comporte des fonctions superbement implémentées, avec une excellente prise en charge du processus projet, il est nécessaire de le compléter pour couvrir tout le périmètre de l’usine de développement. IBM propose tout ce qu’il faut (Rational Quality Manager, Rational Build Forge, etc) mais il faudra finalement acquérir, installer et paramétrer tous ces produits pour qu’ils puissent cohabiter. Leur documentation révèle effectivement qu’il s’agit d’outils distincts, qui réclament un effort d’intégration malgré leur capacité à communiquer à travers Jazz et OSLC. Si l’ensemble a un fort potentiel, il s’agit finalement d’une plate-forme complexe qui n’est adaptée qu’aux grosses structures menant des projets de grande envergure.

Suite Atlassian

Atlassian est un acteur majeur du domaine qui nous concerne. Connu pour son tracker JIRA, l’éditeur propose les éléments susceptibles de constituer une usine logicielle et notamment une suite en mode SaaS, JIRA Studio.

L’ensemble obtient la note de 3,6, avec des fonctions de très bonne facture et une bonne couverture du périmètre. On note quelques lacunes, telles que l’absence de référentiel de composants et des manques sur les outils de qualimétrie. Malheureusement, à l’instar d’IBM, la constitution de l’usine dans son ensemble passe par la mise en œuvre de nombreux outils distincts et même si Atlassian a son offre SaaS à proposer, elle ne répond que partiellement au besoin d’un outil intégré, simple à installer et prendre en main.

Improve Factory

Improve Factory est proposé par la société Open Wide et repose notamment sur Redmine pour les fonctions de forge.

Le produit obtient la note de 4 et propose une couverture équilibrée de l’ensemble du périmètre. Ce bon résultat tient au fait qu’il a été conçu à partir de notre définition de l’usine de développement. Ses différents modules couvrent en effet les six grandes activités en se basant sur des outils open source reconnus dans leurs domaines respectifs (Redmine, Maven, Hudson, Sonar, Nexus…). Sa valeur ajoutée réside dans l’intégration, avec une procédure d’installation simple et unique ainsi que des ponts entre les outils (tels que l’assistant unifié de création de projet et le partage des habilitations). Ce bon résultat doit être nuancé par le fait que l’usine cible spécifiquement les développements Java mais le produit a le potentiel pour élargir son spectre dans ses futures versions.

Bilan

Bien que cette étude puisse aider à choisir une solution d’usine de développement, elle cherche surtout à mettre en évidence la disparité des produits vis-à-vis du besoin tel que nous l’avons défini. On constate en effet que ce qu’on appelle les forges et les suites d’ALM couvrent rarement la totalité du périmètre et l’usine logicielle clé en main reste un produit rare. Les solutions complètes paraissent pourtant bien utiles tant il est difficile et coûteux pour une entreprise d’investir dans la construction et l’administration d’un environnement complet alors même que les bonnes pratiques et les outils existent sur chacune des activités. Le regain d’intérêt actuel pour ce sujet permet cependant d’espérer des progrès et l’arrivée sur le marché de solutions complètes, matures et simples à mettre en œuvre.

Cet article propose un rapide tour d’horizon des bibliothèques Java permettant la gestion de l’import/export du format CSV les plus répandues, ainsi que quelques éléments de réflexion à considérer pour s’orienter.

Bibliothèque externe ou développement spécifique ?

Si la problématique d’écriture de fichiers CSV pose généralement peu de difficultés, malgré son apparente simplicité la lecture de ces mêmes fichiers peut s’avérer complexe. En effet, si l’on considère l’absence de spécification de référence, ainsi que la possible hétérogénéité des systèmes d’encodage, on obtient une première idée des problématiques possibles. S’y ajoutent entre autres la possible variabilité des séparateurs utilisés d’un fichier à l’autre, l’utilisation ou non des guillemets, la gestion d’éventuelles imbrications des caractères d’échappement… Difficile d’être exhaustif tant les subtilités sont nombreuses.

En conséquence rien n’interdit le développement d’une solution spécifique pour un cas bien identifié, mais dans un contexte d’industrialisation des développements il reste préférable de ne pas réinventer la roue et favoriser l’homogénéité des développements en choisissant un outil suffisamment flexible.

Estimer la robustesse des bibliothèques

Si l’on considère le dynamisme des projets, on constate que peu d’entre eux présentent une activité importante, que l’on considère les forums ou les bug trackers associés. Parallèlement la version courante correspond souvent à un numéro peu élevé.

Ces critères généralement retenus pour estimer à première vue le niveau de maturité et de support d’un projet ne semblent pas adaptés au sujet qui nous intéresse, lequel a priori implique peu d’améliorations et de support sur le long terme. On recherchera néanmoins les signes d’une communauté active via un forum ou un bug tracker animés sans oublier une documentation efficace nourrie d’exemples d’utilisation proches des problématiques cibles.

Fonctionnalités/API

L’ensemble de ces bibliothèques propose évidemment des méthodes pour lire et/ou générer des fichiers CSV, mais les moyens et fonctionnalités complémentaires diffèrent d’un outil à l’autre. On distingue assez rapidement des bibliothèques orientées bas niveau de celles relativement plus évoluées. Les fonctionnalités des premières se limitent le plus souvent à l’extraction des données rendues disponibles dans un format de type String. Les plus complètes proposent une intégration plus directe des données par l’intermédiaire d’un paramétrage à définir.

Les capacités proposées pour la lecture des fichiers varient entre une lecture ligne par ligne suivant un modèle de type Iterator et la génération d’une collection représentative du fichier dans son intégralité. Le plus souvent ces deux fonctionnalités sont présentes.

Pour l’import de fichier, certaines bibliothèques fournissent une API permettant d’accéder directement aux données brutes, d’autres facilitent l’intégration directe des données sous forme de Beans (voire nested Beans), Collections, Arrays et proposent parfois la génération directe de requêtes SQL pour l’intégration des données en base.

La validation des données et/ou la gestion d’erreurs n’est pas systématiquement présente et les rares solutions proposées concernent : la définition d’un filtre sur les données en entrée, l’utilisation d’un handler d’erreurs associée au lecteur du fichier, ou l’utilisation d’une collection chargée de stocker les erreurs rencontrées.

Du point de vue de la gestion du format des données, les fonctionnalités varient d’une gestion manuelle au cas par cas à la possibilité de configurer des transformateurs par donnée, le plus souvent en paramétrant les objets de lecture et d’écriture, et parfois à l’aide d’une configuration XML, voire d’annotations sur les Beans cibles.

Pour permettre le paramétrage du mapping des colonnes, certaines bibliothèques nécessitent un traitement spécifique directement inclus dans le code, d’autres le gèrent moyennant l’utilisation d’annotations, enfin certains outils imposent la définition du mapping dans un fichier XML.

Enfin, au-delà de la gestion du format CSV, ces bibliothèques prennent parfois en charge des formats complémentaires tels que les fichiers à champs de taille fixe, les fichiers à délimiteurs autres, les fichiers XML, XLS, voire la lecture d’enregistrements sur plusieurs lignes, notamment pour traiter la notion de master/detail.

Intégration

Exception faite des classes de tests qui dépendent majoritairement de JUnit, la plupart de ces bibliothèques ne dépendent pas de bibliothèques tierces. Par conséquent l’intégration pourra se faire sans conflits avec les dépendances des projets considérés.

Ces bibliothèques sont en majorité soumises à la licence Apache v2 ce qui facilite leur intégration, notamment pour une utilisation professionnelle.

Synthèse comparative

NB : Les valeurs à « non » de ce tableau ne sont généralement pas à prendre comme un non ferme pour au moins deux raisons : il se peut que la fonction soit présente sans qu’elle ait été constatée, cette fonction pourrait être incluse dans une version non disponible au moment de l’écriture de cet article.

NB2 : Nous n’avons pu considérer le projet JFileHelper pour cause d’indisponibilité du site correspondant.

Evaluation

L’ensemble de ces bibliothèques propose l’export au format CSV à l’exception de BeanFiles qui n’inclut pas cette fonction ainsi que csvtosql qui exporte les données sous forme de requêtes SQL.

Maven est prêt à l’emploi avec les bibliothèques suivantes : BeanIO, Commons CSV, csvtosql, JCSV, OpenCSV.

Mis à part BeanFiles (LGPL), JavaCSV (LGPL), et Ostermiller CSV (GPL), l’ensemble de ces bibliothèques est sous licence Apache v2.

Exercice difficile mais utile, une notation est proposée à titre indicatif sur des critères subjectifs. Cette note souhaite rendre compte du niveau de chaque outil relativement à l’ensemble des autres. On pourra donc interpréter la valeur « ++ » comme « dans la moyenne » et considérer les valeurs adjacentes « + » et « +++ » respectivement comme « en retrait » et « plus évolué ».

Considérant l’absence de données comparables, les critères de popularité et de qualité de la communauté ne sont pas traités.

Bilan

Les différentes recherches effectuées montrent une certaine prépondérance de la librairie OpenCSV au sein de la communauté open source. Gage de qualité, cette observation nécessite tout de même de considérer une API majoritairement orientée bas niveau.

Dans un registre similaire, les bibliothèques JCSV, SuperCSV et FlatPack apparaîssent comme des candidats relativement complets.

Parmi les projets les plus récents on notera l’émergence de BeanIO, l’un des plus complets en matière de fonctionnalités, déjà intégré dans le projet Apache Camel et compatible avec la solution SpringBatch.

Parallèlement, notons que la vocation affichée de Commons CSV et son affiliation à la communauté Apache semblent prometteuses sans pour autant convaincre étant donné le manque flagrant d’informations et manque de maturité (version 1.0-SNAPSHOT).

Il faut noter que les performances de ces bibliothèques à l’exécution n’ont pas été évaluées. Cet aspect reste un élément important qui devra sans doute être pris en considération pour le choix d’un outil.

Enfin, précisons que d’autres solutions existent mais ne font pas l’objet de cet article. Citons notamment des solutions intégrées destinées à un contexte d’utilisation plus large telles que SpringBatch, Apache Camel ainsi que les ETL en général.

Cet article se propose de revisiter les tares courantes des projets d’informatique de gestion pour les confronter aux pratiques et outils disponibles. Le sujet étant très vaste, nous l’aborderons ici à travers les notions d’ « usine de développement », de « forge » et d’ « ALM » dans le cadre des technologies Java. L’objectif est de dégager des pistes de progrès pragmatiques et abordables car s’il est illusoire de faire du rêve une réalité, il y a sans doute moyen d’éviter le cauchemar !

Le cauchemar des DSI

Imaginons un instant que nous soyons confrontés à la pire situation pour une DSI et faisons un rapide tour d’horizon des problèmes rencontrés lors des projets informatiques. Si ce scénario peut paraître extrême, la nature des difficultés mentionnées n’est malheureusement pas absente du quotidien des DSI.

La première source de soucis concerne l’expression et la prise en compte des exigences, ce qu’on appelle aussi les spécifications fonctionnelles. Sans évoquer les carences d’organisation, il est courant de constater que les utilisateurs ont du mal à communiquer leurs besoins et à les faire prendre en compte par l’équipe qui réalise l’application.

Les attentes sont finalement mal exprimées et mal comprises et les fonctions réclameront en conséquence des ajustements tardifs, risqués et coûteux. Les demandes d’évolution, les dysfonctionnements sont mal remontés et les utilisateurs s’en accommodent dans la mesure où leur prise en compte est perçue comme aléatoire. Quand il y a de bonnes idées, elles sont lancées devant la machine à café et jetées avec les gobelets…

Le cauchemar continue du côté des équipes de réalisation. Quand il y a des règles de développement, pratiques reconnues ou choix d’entreprise, elles sont mal appliquées. Pire : on ne sait même pas dire si elles sont appliquées ou pas. Sans contrôle, chacun procède comme il veut, dans son coin. Certains choix se font de manière implicite, sans concertation ni justification, voire même sans aucune communication sur le fait qu’un choix a été fait. C’est ainsi qu’on découvrira trois ans plus tard qu’un framework open source a été intégré à une application dans une version non identifiée et avec une licence litigieuse.

Par ailleurs, on a peu de moyens d’assurer qu’une évolution n’entraînera pas une régression des autres fonctions. Il n’y a pas d’alternative entre les recettes coûteuses et la stratégie du « on verra bien ». Mais si une erreur a été commise, ses conséquences seront visibles si longtemps après qu’il sera difficile d’en comprendre la cause et de mettre en œuvre un correctif.

Il arrive souvent qu’un développeur passe des heures à résoudre un problème alors que quelqu’un dans l’équipe l’a déjà résolu. De toute façon, ce dernier a perdu les informations utiles. Et quand chaque développeur a terminé son travail, on s’aperçoit qu’on est loin du compte : produire le livrable final demande un effort colossal qui est lui-même source d’erreurs, corrigées à la va-vite. Le déploiement en production est ensuite une guerre de tranchées entre l’équipe d’exploitation et celle des développeurs. L’une est responsable, l’autre est coupable.

In fine, chaque projet produit une application différente du point de vue technique et les personnes chargées de la maintenance devront s’adapter à chacun de ces contextes, avec le risque de confusion que cela comporte. De toute manière, avec le temps, l’activité de maintenance ignore ce qui s’est passé pendant le développement initial : on a perdu l’historique, les documents sont introuvables ou inexploitables et il arrive même qu’on ne soit pas capable de retrouver le code source correspondant à l’exécutable en production… Le flou de la phase projet a laissé place à un épais brouillard. Les bons développeurs fuient cette activité périlleuse : la maintenance est un exercice d’équilibriste sans filet donné à des artistes de seconde zone. C’est pourtant là qu’il faudrait des prodiges !

Reste le management. Dans ce cauchemar, le chef de projet se trouve coincé entre des utilisateurs qui demandent l’impossible et des techniciens qui le mènent en bateau. Il lui est difficile d’évaluer des charges et d’arbitrer sur des priorités. Comment identifier les points urgents et stratégiques quand l’information est parcellaire, peu fiable, difficile à analyser dans son ensemble ? S’en suivent des décisions arbitraires, des choix incohérents, des efforts mal ciblés. Cueilli à froid le manager aura du mal à détailler où en est son projet car il faut du temps pour préparer un reporting pertinent. Forcément, la réactivité s’en ressent et les dérapages sont corrigés tardivement, quand ils peuvent l’être.

Le rêve de l’usine de développement

Tous ces acteurs semblent bien inefficaces ! Pourtant, ce n’est pas forcément dû à une incompétence individuelle. Chacun fait comme il peut dans le cadre qui lui est donné. Ne pourrait-on pas offrir aux projets un cadre plus favorable ?

Le cadre idyllique est fait d’agilité, ce qui sous-tend une bonne communication et une grande réactivité. Dans ce rêve, on se donne les moyens de détecter tout écart dès qu’il survient et de mettre en œuvre l’action corrective au plus vite. Les problèmes ne sont pas niés mais tués dans l’œuf. Les décisions sont prises en toute connaissance de cause et tous les acteurs sont impliqués.

Ces pratiques s’organisent via des méthodes de projet dites « agiles » telles que Scrum. S’y adjoignent des habitudes complémentaires, principalement issues du monde du logiciel libre. Ainsi la dispersion des acteurs, l’esprit communautaire et bénévole du contexte open source ont paradoxalement aidé à rationaliser les processus des projets informatiques d’entreprise.

La notion de « forge », partie de l’idée de créer un site internet pour représenter les projets sur le réseau, prend finalement la forme d’un portail collaboratif qui centralise toutes les informations, favorise les échanges et permet à tous les acteurs d’œuvrer dans le bon sens.

A l’heure où la construction d’une application exécutable ne se limite plus à une phase de compilation du code, l’automatisation du « build » s’est imposée et s’étend à des pratiques que l’on rassemble sous le terme d’« intégration continue ».

Tous ces usages permettent d’aboutir à une « industrialisation » des projets et on parle alors d’ « usine de développement » à l’image de ce qui se passe dans l’industrie. On met ainsi en place la « supply chain » de la production logicielle. Voilà une image rassurante mais en quoi consiste-t-elle finalement ?

La planification et le pilotage

Pour commencer, il s’agit de recueillir les demandes des utilisateurs, de les valider, puis de planifier leur prise en compte en définissant des priorités et des moyens.

Dans une forge de développement, les principes du « bug tracker » sont généralisés à toute demande nécessitant une action et un pilotage de celle-ci. Qu’il s’agisse d’une anomalie à corriger, d’une tâche à accomplir ou d’une simple échange d’information, on peut tout suivre. Les utilisateurs peuvent donc exprimer leurs attentes et leurs remarques, l’équipe de réalisation y répondre et les managers superviser ces dialogues, décider des priorités, planifier les travaux et s’assurer de leur aboutissement.

L’approvisionnement

Le code source est stocké et partagé dans un référentiel, dont la fonction est assurée par un système dit de « gestion de configuration ». Ce dernier ne se contente pas de sauvegarder le code de certaines versions identifiées mais va jusqu’à conserver la totalité des évolutions qui ont eu lieu de manière à pouvoir retracer toutes les transformations, en comprendre la logique et si besoin opérer des retours en arrière. Le code source constitue ainsi la matière première entrant dans notre usine. A ce titre, le développeur n’est pas un ouvrier mais un fournisseur qui vient déposer ce qu’il a produit dans cet entrepôt.

D’ailleurs, comme les applications reposent souvent sur des briques externes au projet, à commencer par les frameworks open source, il convient aussi d’en organiser l’approvisionnement. On dispose ainsi d’un référentiel de bibliothèques, sorte d’entrepôt de pièces détachées. Les briques logicielles réutilisables y sont soigneusement stockées par fournisseur et par version pour pouvoir en faire usage le moment venu.

La chaîne de fabrication

Selon les principes de l’intégration continue, le processus de « build », se compose de plusieurs étapes automatisées et standardisées, de la compilation au packaging. Même la production de documentation peut s’y soumettre.

A la fin de cette étape, on dispose au minimum d’un exécutable fraîchement constitué à partir du dernier état du code source et des dépendances définies envers des bibliothèques externes, tout ceci étant issu des référentiels. Peuvent s’y adjoindre d’autres artefacts, comme la documentation ou une extraction du code source qui a servi à cette fabrication.

Le contrôle qualité

Au sein de la chaîne se glissent des phases de tests automatisés : des tests unitaires qui valident le fonctionnement individuel des composants, des tests d’intégration qui vérifient leur bonne cohabitation, des tests de montée en charge qui simulent des situations extrêmes auxquelles l’application pourra être confrontée pour contrôler la fiabilité et les performances.

A cela s’ajoutent des audits de qualité automatiques basés sur des métriques et des règles de développement prédéfinies. C’est ainsi qu’en plus de vérifier la réponse à certaines attentes fonctionnelles, on évalue la qualité de la production, de quoi mettre au rebut le produit s’il n’est pas satisfaisant… Évidemment, un rapport détaillé permettra d’identifier les problèmes et d’initier des actions correctives pour la prochaine fabrication.

La distribution

Il ne suffit pas de produire des livrables encore faut-il les livrer… Que le destinataire soit un client final, l’équipe d’exploitation ou celle de réalisation pour usage interne, l’objectif est de pouvoir retrouver facilement les artefacts en sachant à quelle version ils correspondent.

C’est ainsi que ceux-ci sont stockés et classés dans des zones dédiées, avec une distinction entre les fichiers binaires et les documents. En complément, on peut même envisager un déploiement automatisé sur un serveur pour que le produit soit opérationnel sans aucune intervention extérieure.

Le support

Le support prend avant tout la forme d’un « service après-vente » proposé aux utilisateurs. Ceux-ci peuvent remonter leurs remarques et poser leurs questions. Mais l’activité concerne aussi les échanges internes au sein de l’équipe projet, un développeur pouvant lui-même signaler un problème ou demander assistance à ses collègues.. Dans tous les cas, le support se concrétise par différents moyens de communication complémentaires. Le premier d’entre eux est le « bug tracker » puisqu’il va recueillir les questions et remarques puis donner un cadre aux réponses qui y seront apportées.

Ensuite, il y a des canaux moins formels, comme les forums de discussions ou les systèmes de messagerie instantanée. Leur caractère moins structuré favorise les échanges, le foisonnement d’idées. Enfin, le wiki et la base documentaire permettent de centraliser les informations durablement tout en fluidifiant leur mise à jour et ce, par un maximum d’intervenants.

Bénéfices

On le comprend, l’usine de développement, fortement basée sur l’automatisation des tâches, le travail collaboratif et la centralisation des communications, permet d’éviter de nombreux écueils.

L’enchaînement des tâches de construction et de contrôle étant automatisé, on a tout intérêt à l’exécuter quotidiennement de manière à vérifier au jour le jour la qualité du code produit et à réaliser si besoin les actions correctives nécessaires. Ces dernières se font alors sans douleur puisqu’elles concernent des portions de code limitées, bien identifiées et écrites récemment.

Comme le livrable est reconstruit tous les jours selon le même procédé, on peut montrer l’application à tout instant, demander l’avis des utilisateurs régulièrement et constater très concrètement le travail accompli. La finalisation avant livraison n’est plus une épreuve stressante mais le simple constat que les travaux sont terminés. Sur ce principe, on peut diffuser des évolutions très rapidement tout en limitant les risques. On dispose ainsi des moyens concrets d’application des méthodes agiles.

Enfin, la systématisation des principes du tracker permet de recueillir les exigences, d’arbitrer sur les priorités, de planifier les travaux et de suivre leur exécution à travers des tableaux de bord exhaustifs. Le wiki et les forums assurent la pérennité d’informations complémentaires.

Retour à la réalité

Évidemment, la réalité est moins rose… Mais supposons qu’une entreprise vive plutôt le scénario du cauchemar, que peut-elle faire concrètement pour se rapprocher de celui du rêve ? Existe-t-il une usine de développement telle que nous l’avons décrite ?

Les outils open source

Commençons par une bonne nouvelle : les outils décrits dans notre rêve existent bel et bien. Deuxième bonne nouvelle : beaucoup sont même disponibles en tant que logiciels libres et peuvent donc être évalués et adoptés sans passer par la case achat.

Il serait difficile de passer tous ces outils en revue, mais une petite liste, non exhaustive, s’impose :

• pour les fonctions de tracker : Mantis, Trac, BugZilla, Flyspray, Codendi…
• pour le gestionnaire de code source : CVS, Subversion, Mercurial, Git…
• pour le référentiel de bibliothèques : Nexus, Artifactory, Archiva…
• pour le processus de build : Ant, Maven associés à Continuum, CruiseControl, Hudson ou Jenkins…
• pour l’audit de code et la qualimétrie : XRadar, QALab, Maven Dashboard Report, Squale, Sonar…
• pour les forums de discussion : phpBB, SMF, MyBB, Vanilla, vBulletin…
• pour le wiki : XWiki, MoinMoin, DokuWiki, MediaWiki, PhpWiki…

Bref, il y a de quoi trouver son bonheur. Malheureusement, on pressent que malgré l’accès libre et gratuit à tous ces logiciels, un effort conséquent s’avère nécessaire avant de disposer de l’usine de développement dans son ensemble. En effet, il va falloir choisir les outils en veillant à ce qu’ils puissent cohabiter, puis pour chaque outil l’installer, le paramétrer et plus tard l’administrer en réalisant les sauvegardes et les mises-à-jour. En outre, ces différents éléments vont avoir du mal à communiquer entre eux, ce qui va quand même limiter l’efficacité de la démarche. Il suffit d’imaginer que la création d’un nouveau projet ou l’enregistrement d’un nouvel utilisateur va demander des actions dans une petite dizaine d’outils pour comprendre qu’on est loin de l’idéal.

Les solutions intégrées

Avec le constat qui vient d’être fait, le besoin d’une solution globale apparaît évident. Celles-ci existent, en particulier chez les grands éditeurs : IBM Rational Team Concert, Microsoft Team Foundation Server, Oracle Team Productivity Center, Borland StarTeam…

Ce sont des solutions dites d’ALM (« Application Lifecycle Management »). Évidemment, ce sont des outils monolithiques, spécifiques car fortement propriétaires et plutôt coûteux. Choisir une telle solution peut être pertinent mais c’est un investissement lourd qui sous-entend un choix durable et généralisé, avec une dépendance forte envers l’éditeur concerné. La marche est donc haute et elle n’est probablement pas adaptée à tous les contextes. Force est de constater que les entreprises qui se sont dotées d’une suite ALM de ce type sont encore très minoritaires.

L’approche pragmatique

Le salut vient sans doute d’une voie intermédiaire. Elle repose sur l’existence de solutions intégrées, elles-mêmes basées sur les outils open source déjà évoqués. Ainsi, il est possible d’aborder des pratiques et des outils qui à défaut d’être des standards sont tout de même très répandus. Cela permet de reprendre facilement un existant éventuel, de rester ouvert aux évolutions rapides de ces logiciels, aux futurs formats d’échanges et à des outils complémentaires. Enfin, leur coût se révèle nettement moins élevé que les solutions lourdes des grands éditeurs.

On commence à voir apparaître de telles usines de développement clé en main. Dans ce cadre, l’essentiel du produit est en open source mais on peut aussi bénéficier d’un accompagnement professionnel notamment pour le support. On dispose ainsi d’une solution qui permet une mise en place de l’usine de développement avec « agilité », de manière progressive et ouverte. En complément, certains en proposent même l’hébergement dans le cloud pour un accès en mode SAAS de manière à disposer des bienfaits sans avoir à supporter l’infrastructure et les tâches d’administration. Ainsi le rêve devient même abordable pour les sociétés aux moyens modestes. Bien sûr, l’outillage ne règle pas tout. Pour être efficace, il doit être associé à une volonté et une organisation adaptées mais c’est là la preuve qu’on est bien dans le réel.

Historique et solutions

Les solutions BPM, précédemment limitées au contexte BI, et donc à des applications types basées sur l’affectation de tâches, s’étendent aujourd’hui à d’autres domaines pour lesquels la notion de process est identifiable. Mais surtout, elles s’intègrent à des offres plus larges, comportant ESB et portails.

On distingue deux approches parmi ces solutions :

• celles orientées développeur, avec un accès privilégié aux fonctionnalités du moteur BPM par programmation
• celles orientées utilisateur fonctionnel, avec un accès limité au runtime et l’utilisation d’éditeurs propriétaires pour la définition et la gestion des processus.

Dans les deux cas, des applications dédiée sont souvent proposées pour administrer les tâches créées par le moteur de workflow, cependant on préférera généralement l’intégration directe dans une application métier (utilisation de formulaires personnalisés définis par cette application cible).

La solution open source de référence était jusqu’à présent jBPM de JBoss, dont les créateurs originaux sont cependant partis pour lancer une nouvelle solution, Activiti. La version jBPM5 est donc davantage une nouvelle branche, jBPM4 étant lui directement à la base d’Activti. A travers la nouvelle version de jBPM, JBoss tente de se différencier en promouvant l’intérêt de l’intégration de sa solution avec un moteur de règles (Drools), arguant qu’une solution BPM sans cette fonctionnalité n’est pas concevable. S’ensuit une compétition sur plusieurs forums de discussion, dont celui-ci est représentatif :

http://salaboy.com/2011/01/19/jbpm5-vs-activiti5-dumb-question/#more-1534

Bonita, initialement développé par Bull et à présent proposé par la nouvelle société Bonita Soft, est logiquement à mi chemin entre open source et commercial, préférant contraindre à utiliser ses éditeurs graphiques (qui gèrent jusqu’à la création des formulaires) et limiter l’accès libre au runtime, afin d’inciter à l’utilisation de compléments qui ne sont pas en open source.

Enfin on trouve des solutions dont l’orientation est plus fortement commerciale, comme Intalio, dont la version gratuite community edition est particulièrement limitée. Une telle solution est finalement plus élégante que Bonita, mais chère comparée à Activiti et jBPM (à noter que JBoss cherche à intégrer jBPM à son offre de services globale, payante).

Comme elles représentent déjà un panel assez varié, nous nous sommes contentés d’évaluer ces 4 solutions, même s’il en existe d’autres : Orchestra du consortium OW2, équivalent d’Activiti mais orienté principalement vers le serveur Jonas, Enhydra Shark, plus limité dans sa version community (gratuite, LGPL) et proposé avec des extensions et outils supplémentaires dans une version payante par Together (se positionne commercialement entre Bonita et Intalio), et enfin Process Maker, en licence GPL et technologie PHP.

Notion de tâche

Un worklow BPM est basé sur deux types de tâches :

• des tâches automatiques : elles sont déclenchées lors du parcours de transitions du workflow (celui-ci peut comporter des conditions et des branchements – exécutions en parallèles et jonctions). Les étapes consistent typiquement en l’appel de services métiers. Elles correspondent au principe d’un automate.
• des tâches utilisateur : il s’agit d’étapes nécessitant une action d’un utilisateur (soumission d’informations, choix). Ces étapes suspendent donc l’exécution (ou une branche) du workflow. Elles sont adaptées aux applications utilisant la notion de corbeille de tâches (réponse asynchrone).

Afin d’implémenter les tâches utilisateur, les moteurs de workflow sont souvent associés à un ESB, afin de disposer directement de connecteurs asynchrones.

Normes et standards

Le domaine BPM/workflow est basé sur des standards pour la définition de processus, d’enchaînement de processus et pour l’expression de tâches utilisateur (user tasks) :

BPMN : langage de description de processus (uniquement leur exécution). Les outils étudiés gèrent la norme BPMN 2.0.

BPEL : langage issu de WSFL (Web Services Flow Language) et XLANG permettant de décrire l’enchaînement de services asynchrones, ici des webservices dont les actions issues de leur WSDL sont liées aux processus.

XPDL : format défini par le Workflow Management Coalition (WfMC) afin d’échanger des définitions de processus/workflow (à la fois description de l’exécution et description graphique des diagrammes contrairement à BPEL).

WS-Human Task : norme pour la définition des tâches utilisateur.

PVM (Process Virtual Machine) définit un moteur de workflow indépendant du langage de description

L’idée derrière PVM est de permettre le choix d’un DSL (Domain Specific Language, langage adapté à une problématique particulière) pour chaque aspect (description de processus, description de navigation, mapping O/R, règles, grammaires).

Comparatif

Les informations issues des sites des projets et de divers forums utilisateurs permettent une première analyse, théorique, qui devra être confirmée par la pratique :

De ces informations ont peut tirer la synthèse suivante  :

Notes : 1 (très limité), 2 (limité), 3 (moyen), 4 (bon), 5 (excellent)

Activiti, bien que récent, capitalise sur l’expérience acquise avec les versions précédentes de jBPM. Il bénéficie d’un intérêt plus soutenu de la part des utilisateurs du fait de son activité et de la renommée de ses créateurs dans le domaine. Enfin, contrairement à jBPM, son orientation purement open source est claire (pas de monétisation de solution de services).

Bonita, qui possède une longue expérience et des fonctionnalités/interopérabilité meilleures (comparé à jBPM et Activiti – mais de même niveau que Intalio), prend une orientation commerciale (limitations de la version community), mais évidemment pas encore au point d’Intalio.

En pratique : Activiti vs Bonita

Afin d’affiner le premier comparatif issu des caractéristiques et des divers retours trouvés sur internet, un prototype a été réalisé, en utilisant tout d’abord Activiti (une version jBPM aurait été similaire, du fait qu’Activiti est dérivé de jBPM 4, pour ce cas n’utilisant pas de règles) puis Bonita (approche orientée métier et présenté comme utilisable sans licence commerciale).

L’application prototype met en oeuvre un workflow de gestion d’anomalies :

• soumission d’une anomalie par un utilisateur du groupe reporters (soumission d’un formulaire qui correspond à l’étape initiale d’une instance de processus).
• accès à la liste de tâches de type review (analyse/pré-validation) des soumissions d’anomalie, et validation (avec informations complémentaires) ou rejet par des utilisateurs du groupe reviewer.
• accès à la liste des tâches de type resolve (anomalie à résoudre) et soumission d’un formulaire pour clôturer un bug corrigé par les utilisateurs du groupe developers (les tâches pour ce groupe sont créées par la validation des tâches de type review par les utilisateurs du groupe reviewers).

Afin de tester la facilité d’intégration des solutions avec des frameworks applicatifs existants (notamment pour les formulaires de saisie), les solutions Struts et Struts Layout ont été utilisées (les objets ActionForm représentant les propriétés saisies dans les formulaires utilisateur ).

L’étude préalable a été volontairement réduite (lecture du premier chapitre de Activiti in action et recherche dans quelques forums sur internet pour Activiti, documentation fournie et forums internet pour Bonita) afin d’évaluer l’intuitivité des deux approches et la présence d’informations nécessaires pour accéder au runtime.

Activiti

Orienté développeur, Activiti propose des services techniques pour soumettre les propriétés de user tasks forms ou rechercher des tâches (créées par le moteur de workflow) à partir de critères (groupe d’affectation, etc.) :

• RuntimeService : permet de créer une instance de processus d’après son identifiant de définition (précisé dans le fichier xml à la norme BPMN 2), et rechercher des instances d’un processus.
• FormService :soumet les propriétés (valeurs des champs) du formulaire associé à l’étape initiale (start event), ou soumet les propriétés d’un formulaire associé à une user task.
• TaskService : permet de recherche des tâches suivant des critères.

Descripteur de processus

<process id="bugReport" name="Bug reporting process">

<startEvent id="submitBugReport" activiti:formKey="submitBugReportForm">
 <extensionElements>
  <activiti:formProperty id="project" />
  <activiti:formProperty id="version" />
  <activiti:formProperty id="summary" />
 </extensionElements>
</startEvent>

<sequenceFlow sourceRef="submitBugReport" targetRef="reviewBugReport"/>

<userTask id="reviewBugReport" name="Review bug report" activiti:candidateGroups="reviewers" activiti:formKey="updateBugReportForm">
 <extensionElements>
  <activiti:formProperty id="project" />
  <activiti:formProperty id="version" />
  <activiti:formProperty id="summary" />
  <activiti:formProperty id="priority" />
  <activiti:formProperty id="taskId" />
  <activiti:formProperty id="result" />
 </extensionElements>
</userTask>

<sequenceFlow sourceRef="reviewBugReport" targetRef="reviewResultExclusiveBranch"/>

<exclusiveGateway id="reviewResultExclusiveBranch" />
<sequenceFlow sourceRef="reviewResultExclusiveBranch" targetRef="resolveBugReport"><conditionExpression>${result == 'accepted'}</conditionExpression>
</sequenceFlow>
<sequenceFlow sourceRef="reviewResultExclusiveBranch" targetRef="theEnd">
 <conditionExpression>${result == 'rejected'}</conditionExpression>
</sequenceFlow>

<userTask id="resolveBugReport" name="Resolve bug report" activiti:candidateGroups="developers" activiti:formKey="resolveBugReportForm">
 <extensionElements>
  <activiti:formProperty id="project" />
  <activiti:formProperty id="version" />
  <activiti:formProperty id="summary" />
  <activiti:formProperty id="priority" />
  <activiti:formProperty id="resolution" />
 </extensionElements>
</userTask>

<sequenceFlow sourceRef="resolveBugReport" targetRef="theEnd"/>

<endEvent id="theEnd"/>

</process>

Start event / process instances / tasks

Le start event, étape initiale d’un worklfow Activiti, correspond à une tâche utilisateur particulière : celle-ci ne génère pas de tâche, mais suspend uniquement le workflow (en attente de soumission du formulaire correspondant). De plus l’instance de processus n’est créée qu’au moment de la transition depuis cette étape (donc après soumission du formulaire initial, ici création d’une entrée bug report) vers l’étape suivante (via un service technique Activiti appelé dans l’action Struts).

L’étape suivante, de type user tasks, crée une tâche (de type review) en mémoire pour l’instance de process précédente, et suspend ce dernier jusqu’à soumission du review form correspondant par un reviewer (après sélection de la tâche de type review en attente dans la liste des tâches de type review – voir ci-dessous) :

Le formulaire review permet au reviewer d’ajouter des informations/préciser la demande et accepter (orienter le traitement vers l’équipe développeurs) ou rejeter le bug report (on utilise des instructions conditionnelles dans la définition du workflow en fonction de paramètres résultats de la task form/données soumises – accès direct à l’événement de fin du workflow si rejet).

Si le reviewer valide le bug report (tâche review correspondante complétée et user task form terminée), la transition suivante déclenche/génère une instance de user task resolve bug, affectée au groupe developers.

La documentation trouvée est peu claire/précise sur la distinction entre définition de process (process definition key) et de tâches et instances de celles-ci. Il faut également bien considérer que par défaut les processus persistent en mémoire.

Deux problèmes ont été rencontrés lors du développement du prototype :

• création d’instance de processus additionnelle lors de soumission de start form : un second process est listé dans la liste des taches bug review (l’un avec les données saisies valorisées, l’autre sans les données). En fait la soumission des propriétés d’un formulaire associé au start event démarre un nouveau process, on ne doit pas démarrer explicitement le processus auparavant.
• problème pour terminer une tâche : le taskService ne trouve pas la tâche dont on passe l’id, récupéré pourtant via le service de recherche de tâches, et qui doit donc logiquement correspondre à un id d’instance de tâche existante. Les tâches utilisateurs ne doivent en fait pas être terminées explicitement, elles le sont implicitement (passage à l’étape suivante) lors de la soumission des propriétés du formulaire associé.

Bonita

Le runtime Bonita fournit des services techniques similaires à Activiti :

• ManagementAPI : permet de lire et déployer une archive business (fichier BAR contenant une définition de processus créé et exporté depuis l’éditeur Bonita Studio – voir plus loin).
• RuntimeAPI : permet d’instancier un processus depuis l’id de sa définition dans l’archive BAR (fichier process-def.xml de l’archive), et renvoie l’uuid de l’instance de process créée. Permet également d’affecter une tâche à un utilisateur et exécuter une tâche (pas automatique comme avec Activiti).
• QueryRuntimeAPI : permet de récupérer des tâches selon leur état.

Bonita ne fournit pas d’informations détaillées sur la syntaxe de la définition de processus (fichier process-def.xml de l’archive BAR), ce qui est logique du fait que le mode de développement prévu est d’utiliser l’éditeur Bonita Studio pour les définir. En tous les cas la syntaxe n’est pas homogène avec celle d’Activiti. On s’attendait portant à une description normée, avec uniquement des extensions spécifiques à l’éditeur pour la définition des propriétés des formulaires utilisateur.

Activiti étant orienté développeurs (même s’il propose également des éditeurs) et Bonita étant orienté davantage utilisateurs (même si il propose donc des API runtime), on considérera que l’étape d’export du fichier BAR n’est pas une limitation pour cette comparaison (même si elle a constitué un point de blocage initial dans la mise en oeuvre du prototype).

Dans la pratique (adaptation du prototype Activiti pour le runtime Bonita) on note cependant les limites suivantes par rapport au runtime Activiti :

• La documentation et les discussions sur les forums sont plus limitées.
• La user task/start event initiale (soumission de bug) n’est pas créée automatiquement et le workflow ne génère pas de user task review après soumission de formulaire : il est en effet précisé que si on utilise le runtime Bonita uniquement (donc sans passer par l’éditeur de formulaire de Bonita Studio) les tâches utilisateur doivent être démarrées explicitement via runtimeAPI.executeTask(taskId).

http://www.bonitasoft.org/blog/tutorial/building-your-applications-with-bonita-runtime-%E2%80%93-part-3/

• pas de fonctionnalité/service runtime pour la soumission de données de formulaires associés à des user task (uniquement si définis via l’éditeur de formulaire). L’utilisation de variables d’éxecution de processus est nécessaire.

• possibilité de spécifier des URL externes pour les formulaires (sinon générés) depuis Bonita Studio ; cependant, en plus d’être complexe, cette option redirectToUrl n’est pas proposée dans la version community 5.6.2 mais seulement dans la version Teamwork subscription pack, payante :

http://www.bonitasoft.com/resources/documentation/bos-56/web-applications/use-process-instantiation-form

http://www.bonitasoft.com/resources/documentation/bos-56/web-applications

http://www.bonitasoft.com/resources/documentation/bos-56/web-applications/redirect-form-page-external-url-sp

http://www.bonitasoft.com/products/product-comparison

L’orientation de BonitaSoft semble donc avoir évolué depuis cet article : http://jduchess.org/duchess-france/blog/soiree-bpm-au-lyon-jug-%E2%80%93-rencontre-avec-mickael-istria/

« le BPM est généralement quelque chose d’onéreux, que les concurrents propriétaires vendent à coup des dizaines de milliers de dollars minimum. Si bien que Bonita offre aux organisations la possibilité d’évaluer gratuitement, simplement et sans engagement le BPM avant de se lancer dans l’aventure et d’investir pour obtenir un support professionnel et accéder à des fonctionnalités additionnelles de productivité et d’industrialisation des déploiements »

La réalisation de la version Bonita du prototype dans les mêmes conditions (réutilisation des formulaires Struts existants, pas de licence additionnelle) n’a donc pas été possible.

Conclusion

Dans l’ensemble l’utilisation des solutions BPM/workflows étudiées n’est pas homogène, alors qu’on s’attendait à une approche systématique grâce aux nombreuses normes et standards mis en oeuvre. De plus les notions d’instances de processus et de tâches qui constituent les principes de base ne sont pas suffisamment expliqués, d’autant que la terminologie retenue par les outils ne coule pas de source.

Activiti semble plus intuitif. Les exemples fournis et les APIs permettent de définir, gérer, et intégrer un workflow à une application existante de manière immédiate, et sans limitation. Il est donc bien orienté développeur, pour intégration notamment à un framework existant. Bonita peut être envisagé dans le cadre d’une intégration plus large (moins spécifique) de l’ensemble des outils fournis par BonitaSoft (pouvant alors justifier une souscription).

De manière générale les informations et discussions sur internet pour les deux solutions mises en oeuvre sont encore limitées et ne couvrent pas encore l’ensemble des questions basiques, ce qui constitue un frein à leur adoption dans une approche pure open source.

La forge Improve Factory intègre aussi un processus d’intégration continue permettant de compiler, tester et déployer un ou plusieurs projets. Ce processus s’exécute chaque nuit afin de qualifier et d’intégrer les développements réalisés dans la journée. Elle permet aussi une gestion agile des projets en intégrant les outils respectant la méthode agile Scrum.

La forge Improve Factory se décline en plusieurs offres :

DevBundle : Une forge personnalisée

Cette offre permet de télécharger la forge Improve Factory. Il est alors possible de personnaliser son installation sur ses propres serveurs de développement. Une souscription annuelle permet d’accéder à un support en ligne et aux mises à jour régulières.

DevServer : Une forge clef-en-main

Cette offre propose de louer la forge Improve Factory pour la durée des projets (bail mensuel). La forge est installée dans ses locaux sur un serveur de développement dédié. Ce serveur est fourni clef-en-main et infogéré par l’équipe de support (à distance ou sur site).

DevCloud : Une forge mutualisée

Cette offre propose d’utiliser, via un accès Internet sécurisé, une version mutualisée de la forge Improve Factory. Un abonnement mensuel (fonction du nombre de développeurs inscrits) permet d’héberger, sur les serveurs sécurisés d’Open Wide Technologies, les projets réalisés par des équipes réparties.

A propos d’Open Wide Technologies

Filiale du groupe Open Wide, un des leaders français du logiciel libre, la société Open Wide Technologies développe et distribue :

• La forge de développement Improve Factory, une intégration de solutions Open Source pour le pilotage et l’intégration continue des projets de développement d’applications en Java.
• La plateforme Improve Foundations, une distribution opérationnelle de composants Open Source dédiée au développement et à l’industrialisation de projets en langage Java.

Pour plus d’informations :

http://www.improve-foundations.com/produits/improve-factory/

Venez débattre sur l’avenir de l’Open Source aux Assises le matin, bénéficier des retours d’expérience de gouvernance et modernisation avec Improve Foundations à midi et voir l’après-midi dans le cycle OW2 un aperçu en avant-première du futur EasySOA 0.4 et encore plus avec les experts Open Wide et leurs partenaires.

Malgré un environnement de développement Java devenu plus mature, déployer une chaîne d’intégration continue, organiser une gestion des tests unitaires, sécuriser le suivi des versions ou assurer une mesure continue de la qualité restent des opérations complexes.

Plus largement, les solutions d’ALM (Application Lifecycle Management) ont pour vocation de proposer un processus continu de gestion du cycle de vie d’une application en terme de gouvernance, de réalisation et de maintenance.

Les solutions qui proposent d’outiller ce processus sont souvent complexes et coûteuses à mettre en œuvre. Au cours de ce petit déjeuner, nous vous présenterons la forge de développement Improve Factory, une solution de gestion du processus de développement simple, légère et économique reposant sur des solutions open source.

Adresse : Open Wide Technologies – 23-27 rue Daviel – 75013 – Paris
Contact : technologies@openwide.fr – 01.42.68.28.14

Patrick Benichou, PDG du groupe Open Wide, un des leaders français du logiciel libre, décrit comment l’Open Source et les logiciels libres ont pris une place de plus en plus importante dans les systèmes d’information.

Des exemples concrets expliquent les différentes stratégies d’adoption de ces solutions. Une description de l’évolution des modèles économiques du logiciel libre permet aussi de mieux comprendre la contribution de l’Open Source à la valeur de l’entreprise.

Mais au-delà d’un simple choix technique, Patrick Benichou explique pourquoi les solutions Open Source et les logiciels libres font désormais partie de la gouvernance du SI et sont devenus un chapitre important du schéma directeur défini par les DSI pour répondre aux enjeux de l’économie numérique.

Pour lire l’article :

• Open source : de la clandestinité à la gouvernance au sein du SI

Pour plus d’informations sur une plateforme opérationnelle dédiée à l’intégration de solutions Open Source :

• Improve Foundations – Stratégie Open Source pour les DSI

Les responsables des sociétés, leaders de l’Open Source en France (Open Wide et Alter Way), donnent quelques clefs pour aborder une telle stratégie.

Pour lire l’article :

• Pourquoi diffuser un développement en Open Source ?

En complément, voici 10 règles à retenir pour passer un projet Métier en Open Source :

1. Diffuser un projet Métier en Open Source est une décision stratégique qui doit faire partie intégrante de la gouvernance IT et du schéma directeur de la DSI.
2. Le projet Métier doit être développé de manière générique en proposant soit de paramétrer les traitements fonctionnels en fonction du contexte d’utilisation, soit d’ajouter des modules spécifiques.
3. Il est important de distinguer les parties techniques et les parties fonctionnelles du code source (à l’aide d’une architecture applicative modulaire) afin de favoriser l’ouverture du projet sur de nouveaux domaines et d’améliorer le retour sur investissement.
4. Le soutien d’un partenaire (si possible contributeur du projet), s’engageant à réutiliser le projet pour ses propres besoins, est un atout important pour la crédibilité du projet.
5. L’adhésion de plusieurs acteurs clefs (intégrateurs, SSII, éditeurs…) quant à l’utilisation du projet est un point majeur, notamment pour éviter le désengagement technique des soumissionnaires lors des appels d’offres.
6. La qualité du code source et de la documentation du projet représente un investissement nécessaire sans quoi le projet risque d’être mort-né.
7. Il est nécessaire de contribuer régulièrement aux évolutions du projet pour maintenir sa notoriété et éviter son obsolescence.
8. L’animation régulière de la communauté Open Source du projet est le meilleur moyen de garantir son adoption et d’assurer sa pérennité.
9. Le passage d’un projet Métier en Open Source représente un investissement initial plus important qu’une réalisation spécifique. Le retour sur investissement se mesure dans la durée grâce notamment à la mutualisation de sa maintenance.
10. S’appuyer sur un ou plusieurs projets Open Source existants est un bon moyen de réduire l’investissement initial tout en capitalisant sur la notoriété et la visibilité de ces projets auprès d’une communauté existante.

Pour plus d’information sur l’utilisation d’une architecture applicative modulaire Open Source :

• Improve Foundations – Stratégie Open Source pour les DSI

Elle propose une distribution opérationnelle de plus de 190 frameworks Open Source pour homogénéiser et sécuriser la réalisation d’applications, y compris par des développeurs non experts en Java.

Son principal atout est de réduire sensiblement le budget des projets Java en mutualisant les coûts techniques dans une plateforme partagée par une communauté d’entreprises dont les principaux membres sont :

• Renault
• Galeries Lafayette
• Armée de Terre
• Allianz
• Monoprix
• RSI
• Mutualité de la Fonction Publique
• Chorégie
• Rectorat de Créteil

La version Open Source de la plateforme (Open IF) est téléchargeable sur la forge de la plateforme ( http://www.improve-foundations.org )

N’hésitez pas à nous contacter si vous souhaitez plus d’informations :
technologies@openwide.fr – 01.42.68.28.14