Causes d'échec de l'Intégration continue

Dans certain cas, aux yeux d'une équipe de développement, l'intégration continue se limite à recevoir un mail quand le "build" de l'application échoue. Le problème est que l'intégration continue ne se limite pas seulement à ça...

Il ne faut pas oublier que l'intégration continue n'est pas qu'un outil mais bien un ensemble de pratiques autour de l'ingénierie logicielle. Dans un de ces articles, Martin Fowler présente les pratiques d'intégration continue sur son site.

Voici quelques causes probables d'échecs sur la mise en place d'une démarche d'intégration continue :

• un manque de connaissances de l'ensemble des pratiques d'intégration continue par l'équipe (y compris les managers).

• une mise en place d'un serveur d'intégration continue au niveau d'une équipe projet sans communiquer, informer sur les bénéfices de ce type de démarche et intégrer les principes de fonctionnement que cette mise en place entraine.

Si la volonté de mettre en place ce type de démarche ne vient pas de l'équipe , il faut alors présenter et communiquer autour de la démarche. Il ne faut pas oublier que ce type de pratique est fait pour les équipes de développements et pour leur permettre de travailler efficacement ensemble.

L'intégration continue est avant une histoire de communication. Cela doit être une culture au niveau du projet. Il faut rendre "fun" la pratique de l'intégration continue!

Supprimer les EJbs par Spring

J'ai procédé chez mon client à la réalisation d'une étude sur la suppression des EJBs Sessions sur un de leur applicatif java.

Pourquoi supprimer les EJBs Sessions?

• Pour simplifier l'architecture logicielle de l'applicatif.
• Pour simplifier la plateforme de développements.
• Pour simplifier le processus de construction de l'application.
• Pour augmenter la productivité des développeurs.
• Pour banaliser l'infrastructure serveur (pas de différenciation serveur métier et serveur présentation).
  

Qu'apportent les Ejbs Sessions au niveau de l'applicatif?

• La possibilité de séparer sur des infrastructures différentes la partie présentation et la partie métier. Cette possibilité n'est plus exploitée du fait de leur volonté de banaliser l'infrastructure serveur.

• La possibilité d'appeler la couche Ejbs ( couche "métier") depuis d'autres applications. Ce choix d'interfaçage n'a pas été retenu et il sera pris en charge par la mise en place de Web Services.

• La gestion des transactions. C'est la problématique intéressante qui reste à traiter... avec Spring évidemment...
  

L'intégration de Spring pour prendre en charge la gestion des transactions est réellement facile. Il existe 2 possibilités :

• de façon déclarative dans le fichier de conf Spring.
• Par annotation.

Après avoir testé les 2, j'ai choisi de le faire par annotations. L'inconvénient est d'être intrusif en rajoutant les annotations "@Transactional" dans le code. En revanche, cela augmente la lisibilité au niveau du code. Dans tous les cas, je crois qu'il n'y a pas de mauvaises façons de faire avec Spring mais dans tous les cas des façons "simplifiantes". Voici le lien vers la documentation de Spring qui m'a aidé concernant la gestion des transactions.

Dans le cadre du projet concerné, l'environnement de développement se base sur un simple serveur web Tomcat alors qu'en production, c'est un serveur d'application JBoss. L'applicatif à aussi la particularité d'utiliser un ensemble de datasources.

J'utilise alors un transaction manager différent selon l'environnement :

• Dans l'environnement de développement avec Tomcat, je ne pouvais pas me servir du transactionManager proposer par Spring (org.springframework.jdbc.datasource.DataSourceTransactionManager) car il ne gère qu'une seule source de données. Un article sur le site javaworld explique comment mettre en place un "ChainedTransactionManager" qui s'appuie ensuite sur le transactionManager de spring et permet de gérer plusieurs datasources. Voici un extrait de conf spring correspondante :
  

   <!-- aop pour la gestion des transactions -->
  <tx:annotation-driven transaction-manager="txManager" />
  
  <!-- recuperation des datasources en jndi -->
  <jee:jndi-lookup id="datasource1" jndi-name="jdbc/ds1" />
  <jee:jndi-lookup id="datasource2" jndi-name="jdbc/ds2" />
  <jee:jndi-lookup id="datasource3" jndi-name="jdbc/ds3" />
  <jee:jndi-lookup id="datasource4" jndi-name="jdbc/ds4" />
  
  <!-- declaration du transaction manager -->
  <bean name="txManager" id="txManager" class="com.springsource.open.db.ChainedTransactionManager">
  <property name="transactionManagers">
  <list>
   <bean class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource" ref="datasource1" />
   </bean>
   <bean class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource" ref="datasource2" />
   </bean>
   <bean class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource" ref="datasource3" />
   </bean>
   <bean class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource" ref="datasource4" />
   </bean>
  </list>
  </property>
  </bean>

• Dans l'environnement de production avec Jboss, pas de soucis, j'utilise le transaction manager JTA de spring (org.springframework.transaction.jta.JtaTransactionManager). Voici l'extrait de la conf Spring correspondante :
  

   <!-- transaction manager JTA -->
  <bean name="txManager" class="org.springframework.transaction.jta.JtaTransactionManager" />
  
  
  <!-- aop pour la gestion des transactions -->
  <tx:annotation-driven transaction-manager="txManager" />

  
  

Maven et les dépendances transitives

Une des évolutions de maven2 par rapport à maven1 concerne la gestion de dépendances transitives : La définition d'une dépendance au niveau d'un projet entraîne la récupération des dépendances de cette dépendance et ainsi de suite...

Sur de gros projets, la gestion des dépendances avec Maven est quasiment indispensable. J'ai même dû mal à comprendre qu'on puisse faire sans.

Avec les dépendances transitives, on se retrouve vite à récupérer la terre entière et à avoir des dépendances qui utilisent des dépendances transitives communes mais dans des versions différentes...

On voit apparaître des exceptions du type "NoClassDefFoundError" à l'exécution et c'est là que le casse tête commence...

Voici ce que j'utilise pour résoudre ce genre de problème :

• la commande du plugin maven "dependency" pour découvrir les dépendances en double :
  

  mvn dependency:tree

• La mise en place de tags d'exclusion au niveau des pom.xml pour permettre de définir une dépendance mais d'exclure certaines de ces dépendances transitives :
  

  <dependency>
   <groupId>yourDependencyGroupId</groupId>
   <artifactId>yourDependencyArtifactId</artifactId>
   <version>yourDependencyVersion</version>
   <exclusions>
     <exclusion>
       <groupId>ExcludedTransitiveDependencyGroupId</groupId>
       <artifactId>ExcludedTransitiveDependencyArtifactId</artifactId>
     </exclusion>
   </exclusions>
  </dependency>

Scrum fait peur

Et plus largement les méthodes Agiles.

C'est le constat que je peux faire dans le contexte dans lequel j'évolue.

Je me suis longtemps dit qu'en effet, se lancer dans un premier projet en Scrum peut faire peur alors que l'on n'a jamais fait cela auparavant. En revanche, lorsque le contexte le permet, que des gens compétents sur le sujet y participent et qu'il n'y a pas réellement de risques à faire "un essai" ( :-) les experts comprendront...) , j'ai plus de mal à comprendre...

Une des grosses évolutions par rapport à des méthodes de gestion de projet dites "traditionnelles" (ou plutôt celles qui ne fonctionne pas ou peu) concerne le métier de chef de projet qui n'existe plus car il est remplacé/transféré par le rôle du ScrumMaster.

En se mettant un peu à la place d'un chef de projet, il est plus facile de comprendre (mais pas forcément d'accepter) leurs points de vue. Imaginons qu'on vienne vous dire que votre façon de travailler depuis des années soit totalement remise en questions, que des retours d'expériences vous démontre que c'est presque une évidence et que vous n'y avez pas pensé. Cela ne doit pas être évident à encaisser...

Messieurs les chefs de projets, je vous le dit :
Scrum ça n'est pas l'avenir, c'est tout de suite! Allez-y!

Juste pour le fun, une petite tendance à la google :


en bleu : rational unified process
en rouge : Scrum agile

Comme le précisez Claude Aubry sur son blog dans ce billet en 2007, il faut faire attention à ne pas créer un Buzz autour de Scrum et le transformer en une méthode un peu originale et à la mode. Scrum c'est avant tout un ensemble de pratiques simples et pragmatiques à mettre en œuvre pour réussir un projet.

Une métaphore de Scrum

Le Touilleur Express vient de publier une métaphore permettant d'expliquer les grands concepts autour de Scrum.

Pour Simplifier, Scrum : c'est une machine à laver. J'adore.

Je vous laisse aller lire le billet du Touilleur Express sur le sujet pour avoir plus d'infos.