Voici 3 videos de plateaux TV (techtoc.tv), où Olivier LEAL et moi-même avons participé, sur divers sujets autour du Cloud Computing tels que :

o Migration du SI vers le Cloud : à quelles conditions ? Pour quelles parties du SI ? Pour qui ?, revue des bonnes pratiques déjà établies pour se déterminer à aller vers le Cloud, et vers lequel.

——————————————————————————————

o Impacts du Cloud sur la gouvernance des SI ?, redistribution des cartes !

——————————————————————————————

o Ou bien encore Le Cloud pour ma PME ?, les grandes entreprises auraient-elles plus d’avantages à utiliser le Cloud qu’une PME ? Ou les raisons sont-elles ailleurs ?

Je les mets à votre disposition si vous souhaitez les regarder !

Frédéric FAURE @Twitter @Ysance

• la mise en place d’un Atelier de Génie Logiciel ;
• le déploiement de postes de développement uniformes ;
• l’industrialisation des tests.

Si l’objectif est simple, la logistique devant permettre d’atteindre ce résultat repose sur plusieurs fondamentaux.

Partager
Le déclenchement des activités d’intégration continue repose sur le déploiement des derniers développements. Un référentiel de code (gestion de version) est donc nécessaire pour le partage et la détection des dernières modifications. On distingue différentes générations d’outils :

• CVS
• Subversion
• Git, Mercurial

Du point de vue de l’intégration continue, peu importe l’outil pourvu qu’il y en ai un (ce qui n’empêche pas qu’il y ait des différences et des orientations divergentes  d’un outil à l’autre, mais c’est un autre sujet).
2 stratégies peuvent ensuite être mise en place :

• des intégrations cycliques (généralement toutes les nuits) pour avoir en ligne le matin les travaux réalisés la veille. Ce dispositif peut être complété par la possibilité de déclencher des intégrations supplémentaires à la demande, par exemple en cas d’une grosse avancée dans la journée.
• un hook du gestionnaire de version. La majorité des gestionnaires de sources sont prévus pour permettre l’exécution d’un script après certains événements. Par exemple, on peut ajouter un script d’exécution de l’intégration pour chaque commit.

Le choix de la stratégie va dépendre de plusieurs facteurs. A-t-on besoin d’une intégration continue à jour à chaque commit ? En fonction de la technologie employée, de la taille du projet, l’étape de compilation et les différentes opérations peuvent prendre un temps significatif pendant lequel l’espace d’intégration n’est potentiellement pas dans un état stable.

Déployer
La principale problématique est en fait la capacité à déployer rapidement et facilement sur un serveur le travail réalisé. Par déploiement, il faut comprendre la réinstallation des sources sur un environnement vierge. Il faut donc effacer l’installation précédente (fichiers et base de données), recompiler si besoin, éditer les fichiers de configuration, réimporter la base, etc …
Ce processus d’intégration continue n’est réaliste que si le déploiement est automatisé. C’est donc un des points critiques.
Évidement, on peut résoudre ce point avec un classique script shell. Il existe toutefois des outils spécialisé comme Make (C, C++), Ant (plutôt lié à Java), Phing (php uniquement), Rake (ruby), …
Ant est une référence dans le domaine. Au delà du déploiement  sur la plateforme d’intégration continue, le script doit également permettre de déployer le projet dans les autres environnements (recette client, pré-production, production, etc…) et de lancer les différents tests et mesures sur le code source.

Ordonnancer
L’intégration continue, implique que le déploiement se fasse en continue. Il doit être déclenché périodiquement ou, mieux, à chaque commit.

Tester
Les tests sont la véritable justification de l’intégration continue. Ils vont permettre de vérifier la non régression de l’application et éventuellement l’avancement du travail dans le cas d’un développement piloté par les tests (TDD, Test Driven Development). .
Par ailleurs, pour les applications Web basées sur un incontournable modèle MVC, les tests d’interfaces peuvent se révéler plus pertinents. Ils sont également les seuls à pouvoir permettre la détection de problèmes de compatibilité entre le code des interfaces et les navigateurs.

Apporter des métriques au projet
L’intégration continue a des retombées sur les métriques. Une fois automatisée, on peut bénéficier de l’infrastructure mise en place pour lancer différentes analyses sur le code :

• Inventorier les duplications de code pour lutter contre les copier/coller. On limite aussi l’augmentation de la taille du code au bénéfice de la factorisation. Les évolutions et la maintenance s’en trouvent simplifiées.
• Utiliser un parseur de normes pour cataloguer les transgressions des normes de codage du projet. Un outil analysant la présence et le ratio de commentaires par ligne de code est inclus dans le parseur. La détection du code mort peut également l’être. Ces éléments sont la garantie d’avoir un code plus facile à maintenir, car lisible.
• Mesurer les valeurs de différentes métriques/statistiques tels que la complexité cyclomatique ou le ratio d’abstraction. La complexité cyclomatique mesure le nombre de chemins possibles dans l’exécution du code (un « if » compte +1) . Plus le code est « complexe » plus il nécessite de tests pour couvrir les différents chemins d’exécution.  Le ratio d’abstraction est calculé en dénombrant le nombre de classes abstraites divisé par le nombre total de classes.

Serveur d’intégration continue
Généralement, cet élément captive l’attention alors qu’il ne fait pas grand chose (ce qui ne veut pas dire qu’il ne sert à rien ;-)).
La référence dans ce domaine est Hudson, renommé Jenkins dans sa version open-source suite à l’évolution de la politique d’Oracle (qui donne LibreOffice pour OpenOffice et MariaDB pour MySQL).
Si Hudson est issue du monde Java, il est utilisable avec un grand nombre de langages vu le nombre très important de plugins disponibles. CruiseControl est autre un serveur d’intégration continue écrit en Java (et CruiseControl.net pour .NET). Contrairement à Hudson qui bénéficie uniquement d’une interface web, CruiseControl bénéficie d’une interface graphique cliente.

CruiseControl

Hudson

L’intégration continue repose sur de nombreux composants pour le déploiement, l’ordonnancement, les tests, la métrologie : le serveur d’intégration continue est le liant qui va permettre d’offrir une vue cohérente de l’activité d’intégration continue. Le serveur d’intégration continue va récupérer les résultats des tests et des métriques pour les afficher de manière synthétique et chronologique. Finalement, on pourrait faire de l’intégration continue sans serveur d’intégration : une fois un hook installé sur le gestionnaire de sources pour lancer le script d’intégration continue, les résultats des tests et les métriques peuvent être rendus disponibles dans un répertoire partagé.
Le serveur apporte un confort d’utilisation et une souplesse très importante au quotidien. Il permettra à un chef de projet de lancer un nouveau « build » sans taper une ligne de commande shell. Il offrira également l’historique des builds de manière consolidée.

En fait l’intégration continue n’est pas un nouvel outil : elle n’existe pas en tant que telle.
L’intégration continue est l’utilisation d’outils existants de manière coordonnée et centralisée pour obtenir un suivi de l’avancement et de l’état du développement d’un projet.

François LASSELIN @Twitter @Nalis

Je me présente : Olivier Léal, Directeur de Missions (opérationnellement Directeur Technique et Architecte Sénior) chez Ysance. Pour un premier article, je profite de notre média pour dire tout haut ce que beaucoup d’architectes pensent tout bas…

Parlons donc de ces frameworks qui nous font rêver en phase d’étude et de conception puis qui nous font pleurer en production.
Pour moi, « la bonne réalisation d’une application informatique repose sur l’expérience de concepteurs professionnels et non pas sur une utilisation de frameworks mal connus et pas du tout maitrisés. »

Pour ne prendre qu’un exemple, combien de développeurs en informatique déclarant connaître Hibernate connaissent réellement son fonctionnement et sont capables de l’utiliser afin de délivrer une application qui ne rencontrera pas de problèmes de montée en charge quand il s’agira d’exploiter le volume de données en production.

Avec la propagation des méthodes agiles, où sont passées les phases de conception technique générale et détaillée. Qui se pose la question des règles de passage d’un modèle de classes métiers au modèle de classes techniques ? Est-ce qu’un architecte intervient en continu sur le projet : de l’étude jusqu’à la mise en production ?

Combien de développeurs/concepteurs ont une bonne connaissance des Design Pattern de base permettant de concevoir et de faire évoluer une application (factory, singleton, business object, business service, …) ?

Résultat…
Beaucoup de projets informatiques reposent sur l’utilisation de frameworks mal utilisés du type Hibernate, Struts, … L’exemple le plus courant est Hibernate avec des développeurs qui pensent que son utilisation permet de s’affranchir de la connaissance du SQL et des bonnes pratiques de conception. Les constats les plus courants sont des applications qui ne tiennent pas la charge en production et qui, par voie de conséquence, donne naissance à des infrastructures sur-dimensionnées pour répondre aux besoins.

A cela certains répondent, qu’il est plus profitable d’avoir des développements moins coûteux en utilisant des ressources moins compétentes et d’avoir des infrastructures plus importantes. On trouve principalement ce genre de réflexions dans les groupes où les coûts récurrents de gestion et de maintenance d’infrastructure ne sont pas répercutés sur le coût des projets.

Résultat, des équipes projets qui se trouvent bloquées et qui n’ont pas la maîtrise de leurs applications quand commencent les tests de montée en charge ou, bien souvent, l’utilisation directe en production :

• Une application qui s’écroule en charge ? Combien de développeurs répondent : « Mais pourtant ça fonctionnait très bien unitairement sur mon poste de développement… » !
• Une application parfois partielle ? Combien de développeurs remontent  : « Ha… En effet… Comment mes objets sont instanciés dynamiquement ? Je ne me suis pas aperçu que j’avais oublié de livrer la classe xxxx » !

Une fois que l’on a dit ça… Que faire ?

1. Sql ou NoSql, un concepteur/développeur doit dans son métier connaitre les bases de données. L’architecture des données dans une application informatique est cruciale dans un monde ou la taille des bases de données explose.
2. Le MDA (Model Driven Architecture) et le MDE (Model Driven Engineering) bien trop méconnus pour le moment. L’outillage de conception doit permettre aux concepteurs de maîtriser la structure des applications par l’utilisation de générateurs de code pour obtenir :

• une application documentée,
• des principes d’architecture systématiques et adaptables au cours des développements par la modification des chaines de génération de code.

Une des solutions gratuites du marché MDA que j’ai expérimentée très positivement est Acceleo, mais il en existe d’autres. Il s’agit d’un générateur de code basé sur les modèles d’Eclipse EMF. Ecrit en JAVA, ce générateur de code « gratuit » permet de driver n’importe qu’elle type de code. Associé à un outil de conception UML, on peut se constituer rapidement un outil gratuit pour concevoir assez efficacement une application.

Mieux, mais payant, la solution MDE Obeo Designer permettant de bâtir directement des concepts métiers bien plus faciles à comprendre par une MOA que des classes UML avec des stéréotypes.

Suivant les réactions à cet article, je vous proposerai dans les prochains articles des solutions visant à employer ces concepts dans des projets agiles et industrialisés.

Olivier LEAL

La clé est d’organiser le projet de façon modulaire en évaluant correctement les différentes briques fonctionnelles et techniques du projet à mettre en place.

Nous prendrons dans notre exemple le cas d’un projet développé sous Eclipse et dont le serveur d’application cible est Tomcat. Tout autre technologie est bien sûr envisageable.

Le découpage des sources
Tout d’abord il conviendra d’effectuer un découpage fonctionnel des différents modules ou accès de l’application. Nous pouvons prendre le cas d’un projet proposant un Back Office et un Front Office. Chaque module fonctionnel sera déclaré comme un projet à part entière et consommera des fonctionnalités, méthodes et outils communs présents dans un autre projet contenant le framework maison ou tronc commun. Outre une maintenabilité accrue pour l’ensemble du projet par la suite, cela permet de séparer clairement les éléments nécessaires à la compilation et exécution de chaque modules qui pourront s’exécuter sur des environnements/serveurs distincts. En effet, sur un site commerçant par exemple, le Back Office nécessitera probablement une infrastructure minimale afin de remplir les produits qui seront accessibles au grand public sur le Front Office qui pourra nécessiter une infrastructure plus poussée afin de supporter la charge, avec un système de réplication de données master-slave par exemple. Il faut donc que chaque module soit indépendant afin de pouvoir être déployés séparément sur des infrastructures distinctes.

L’intérêt d’avoir un projet à part pour le tronc commun permet en plus d’effectuer des montées de versions rapides pour peu que les méthodes et interfaces dudit framework maison aient été convenablement définies et ne bougent pas ou bien que la rétrocompatibilité soit assurée de manière générale. Cela permet d’avoir une version ISO du framework entre les différents projets (pas au sens Eclipse du terme mais au sens « business ») de la société et que chacun puisse profiter des dernières corrections et évolutions du framework maison.

Concernant les framework du marché, la séparation n’est pas aussi simple puisque, plus qu’un ensemble de méthodes et d’outils, ils proposent des modèles de développement, et donc qu’en général, les sources sont intégrées directement dans leur modèle, comme dans Struts pour ne citer que lui. Il n’est donc pas nécessaire de vouloir extraire dans des projets séparés tous les framework, car cela ne serait pas forcément bénéfique.

Le cas des outils éditeurs
Reste en suite le cas des outils éditeurs, par exemple, qui bien souvent se retrouvent modifiés directement dans leur code source (quand les sources sont disponibles) rendant ainsi toute montée de version insurmontable. Le but de le mettre dans un projet à part est le même que pour le framework, c’est-à-dire de pouvoir profiter des évolutions/corrections du produit proposées par l’éditeur en gardant la possibilité de changer simplement de version. Cette simplicité est accrue avec les qualité des interfaces que doit proposer le tronc commun pour accéder au produit. En effet, lors d’une montée de version, si quelques méthodes de l’outil ont changé, il suffira de mettre jour l’interface du tronc commun correspondante sans avoir à modifier un seul élément du Front ou du Back office.

Si il s’avère que des modifications sont nécessaires afin d’apporter quelques spécificités au produit, il faudra le faire dans un projet à part, en conservant la même logique arborescente que le produit lui-même. Les modifications seront fusionnées avec la version originale de l’outil lors de la phase de génération de la cible via le moteur d’automatisation des tâches.

Le contenu
Certains développements ont pour but de présenter du contenu. On peut prendre le cas d’un projet se basant sur un outil éditeur de type CMS (Content Management Systems ou Système de Gestion de Contenu). Du contenu sera nécessaire lors de la phase de développement. Cependant, le contenu doit se trouver impérativement dans un projet à part :

- pour identifier aisément les ressources « statiques » du site et les « dynamiques » correspondant au contenu,

- pour éviter lors des livraisons dans l’environnement de PROD d’embarquer des éléments de type contenu et d’écraser les modifications effectuées via le Back Office par les responsables du contenu (je suis sûr que si vous avez déjà travaillé sur un projet de CMS vous avez déjà vu ça… Hein !),

- pour ne pas mettre 3 heures à rapatrier votre projet de SVN/CVS (gestionnaire de sources) alors que vous ne vouliez récupérer que les fichiers sources du développement et que vous vous retrouvez avec 1Go de contenu en prime !

La compilation et l’exécution
La compilation des sources est assurées grâce aux dépendances que l’on peut appliquer entre projets. Il n’est donc pas nécessaire de tout mettre dans le même projet pour que cela compile ! ;ob Il faut cependant faire attention aux dépendances cycliques : bien que le compilateur refusera par défaut, il est toujours possible de désactiver certaines barrières, … Il est indispensable de ne pas en avoir car au-delà du fait que l’exécution ne sera pas possible sur l’environnement cible (rien que ça) à moins de tout poser au même endroit, cela signifie qu’il y a un problème de conception. Il n’y a pas de dépendance cyclique des projets si ils suivent une logique de couches correcte.

Concernant l’exécution, elle sera permise grâce à une tâche ANT qui va récupérer les compilés et ressources de chaque projet afin de les mettre à disposition dans un répertoire cible :

- répertoire du plugin Eclipse-Tomcat pour l’exécution en mode « débug »,

- version livrable sous forme de « war » pour plateformes d’INT, de PROD, …

- …

ANT est un scripteur de tâches permettant un ensemble complet de fonctionnalités (compilation, génération de Javadoc, archivage (zip, war, …), extraction CVS/SVN, …). Issu d’un projet Open source de la fondation Apache, il permet l’automatisation et donc la fiabilisation lors de la reproduction d’opérations répétitives tout au long du cycle de développement. Il sera alors possible de créer un ensemble de tâches ANT qu’il suffira d’exécuter : « Livraison DEV », « Livraison PRE-PROD », « Livraison PROD », …

ANT est capable également de se connecter à SVN et de générer les livrables à partir d’une version par exemple, une version des sources devant normalement être générée avant chaque livraison.

Si il est nécessaire d’avoir à disposition un ensemble de données d’initialisation du CMS pour le développement, un projet spécifique de contenu doit être créé et intégré via ANT lors de la génération du « build » dans la target « Livraison DEV ».

Illustration

Structuration-Organisation Projet

Conclusion
L’organisation d’un projet au niveau des sources est indispensable car c’est ce qui va vous permettre d’assurer une maintenabilité et une évolutivité de vos développements, vis-à-vis également des éventuelles montées de version des composants communs ou éditeurs sous-tendant votre projet.

De plus un moteur d’automatisation des tâches de développement est indispensable quelque soit la taille du projet afin de permettre une reproductibilité des tâches, d’assurer une capitalisation des connaissances via ces scripts et également de soutenir l’organisation projet des équipes en permettant, par exemple, à n’importe qui d’effectuer une livraison, et ce rapidement.

L’investissement au niveau de la conception est une économie au niveau du projet dans sa globalité.

Frédéric FAURE