Pour faire simple, imaginez que sur un seul écran vous puissiez voir en un clin d’œil l’état de vos builds (succès/instabilité/échec), le nombre de tests unitaires et d’intégration agrémenté de métriques telles le nombre de lignes de code, la couverture de code et le respect des normes de codages.
Mieux qu’un long discours, nous vous proposons une courte vidéo de 3 minutes qui démontre la facilité avec laquelle vous pouvez démarrer facilement avec l’outil.
Si vous désirez en savoir plus sur le développement de ce projet, nous vous proposons une rétrospective de ces derniers mois, en partant de la genèse du projet jusqu’à son état actuel.
Le 4 Juin 1996, à 9h35 le vol 501 de la fusée Ariane 5 effectue son premier décollage. Quelques secondes plus tard, le système de guidage inertiel reçoit trop d’informations et se met hors service, car reconnu défaillant. L’ordinateur de bord est alors notifié qu’un dysfonctionnement est en cours et compromet les informations concernant la trajectoire de la fusée. Cette modification de la trajectoire entraîne l’arrachage d’un moteur d’appoint, déclenchant l’auto destruction de la fusée. Des analyses plus approfondies ont démontré que le système de guidage inertiel est lui même la cause de cet échec. Conçu à l’époque pour Ariane 4, il n’était plus nécessaire pour Ariane 5. Maintenu actif pour des raisons de commodité, ce système s’est avéré être à l’origine d’un des bugs informatiques les plus coûteux de l’histoire.
Au-delà du caractère spectaculaire de cet exemple, il est intéressant de noter que l’origine du dysfonctionnement réside dans un module développé pour une version antérieure de la fusée et devenu obsolète. Ce vestige de code, maintenu dans l’application sans être nécessaire pour son fonctionnement, est l’une des formes de ce que Ward Cunningham désigne sous le terme de dette technique.
A travers ce document, nous découvrirons en quoi la dette technique ralentit la productivité des équipes et nuit aux projets. Nous mettrons en évidence ses mécanismes sous jacents et les leviers d’actions dont nous disposons. Enfin, nous montrerons comment elle se gère au quotidien, par l’instauration de bonnes pratiques de développement et la mise en place d’outils, pour enfin aborder quelques stratégies complémentaires, mais essentielles pour venir à bout de la dette technique.
Selenium regroupe une suite d’outils permettant de tester des applications web. Tout comme les tests unitaires, Selenium permet notamment de vérifier la non-régression d’une application et est un gage de qualité supplémentaire. Bien que la création des tests Selenium soit relativement simple, automatiser leur exécution sur un serveur d’intégration continue reste complexe à mettre en œuvre. Je vous propose une solution avec l’outil de build Maven. Disposant de nombreux plugins, comme SQL, Failsafe, Jetty et Selenium, Maven permet la mise en place d’une automatisation satisfaisante. Cette solution peut servir aussi aux tests d’intégration.
Nous avons le plaisir de vous présenter notre livre blanc sur la qualité logicielle écrit par Frédéric Dubois, avec la participation de Séven Le Mesle.
Objet du désir, la qualité logicielle est régulièrement invoquée sur le mode incantatoire au démarrage d’un projet de développement logiciel.
Assurance qualité, direction qualité, responsable qualité, qualimétrie, processus unifié, modèle de maturité… nombreux sont les dispositifs visant à garantir que le résultat du développement sera source de fierté pour ceux qui l’ont conçu, de contentement pour ceux qui l’ont financé, de soulagement pour ceux qui devront le maintenir et de satisfaction pour ceux qui l’utilisent et l’exploitent.
Dans un premier temps, ce livre blanc s’attache à définir ce qu’est la qualité logicielle, et à analyser les raisons de son évanescence. Il décrit ensuite un ensemble de pratiques d’ingénierie qui, selon nous, et appliquées de façon systématique, permettent d’écrire, à moindre coût, des logiciels de très haute qualité
Nous espérons que vous prendrez plaisir à le lire.
Le CITCON (prononcé « KITCON ») a eu lieu vendredi et samedi dernier à Paris, pour la session européenne 2009. Vendredi soir, après les présentations d’usage, l’open space a commencé par le remplissage du tableau des sessions par les fameux post-it. Pour rappel, les participants écrivent un thème sur un post-it et le collent n’importe où sur le tableau. C’est autour d’un verre, et entre deux discussions, qu’on vote et place les post-it dans les cases proposées pour chaque session.
Suite à la conférence Qualité du code source et l’intégration continue animée le 26 mai dernier par Nicolas Le Coz et Erwan Alliaume au XP Day France 2009, nous lançons une série de billets autour de la qualité. Voici donc le premier de cette série, il s’agit des slides de cette présentation.
La présentation est découpée de la manière suivante :
La première partie effectue une description générale de la démarche de la mise en place de métriques qualités et introduit pourquoi nos projets ont-ils besoin d’un contrôle qualité.
Une seconde partie revient sur l’intégration continue. Elle décrit en quoi celle-ci va vite nous devenir indispensable dans notre approche.
Vient ensuite la partie solutions. Cette partie répond pratiquement à la question Comment faire du code de qualité ? via une revue des principaux processus, outils d’analyse de code et outils de consolidations
La présentation se termine par un guide pratique qui vous orientera sur les choix à effectuer pour les principaux freins à la qualité : démotivation des équipes, no respect des règles par les développeurs, manquement d’appui par les chefs d’équipes …
Le 25 et 26 mai 2009 se tiendra une série de conférences, XP Day France 2009. Cet événement a pour objectif d’apprendre et de partager sur les méthodes agiles. Xebia aura l’honneur de partager son expertise sur deux conférences :
La conférence Qualité du code source et l’intégration continue a pour objectif de comprendre les enjeux de la qualité du code source dans une démarche d’intégration et d’amélioration continue.
À travers une démarche logique, nous montrerons qu’il n’est pas plus difficile d’écrire du code de bonne qualité. L’objectif principal de cette démarche est de produire du code source dont la dette technique se rapproche au maximum de 0. Il faut donc avoir un plan de bataille pensé et adopté par l’équipe afin d’être efficace. À l’image des tests unitaires, faire de la qualité ne doit pas être vu par l’équipe comme une corvée ou un travail optionnel. Ainsi, pour avoir une démarche efficace et motivante, il faut des règles claires, simples, vérifiables et mesurables. L’intégration continue est le bon candidat pour vérifier de manière régulière et automatisable ces règles ! Les bonnes pratiques et des conseils de mise en œuvre seront alors exposés. Cependant, cette démarche a ses propres pièges et limites, nous verrons lesquels et les conseils pour les éviter !
La présentation sera illustrée par un cas pratique dans lequel nous utiliserons certains produits stars comme PMD, CheckStyle, JavaNCSS ou Sonar pour mettre en place les premières briques de notre contrôle qualité.
Grâce à cette présentation, vous disposerez des armes, arguments et conseils directement applicables pour faire adopter et réaliser à moindre coût de la qualité sur vos projets. Nous espérons vous y trouver nombreux. D’ici là, n’hésitez pas à poser vos questions ici directement sur notre blog ou sur Twitter.
Télécharger en PDF
Complet
Twitter
