Introduction à la gestion des cycles de vie des applications
(Application Lifecycle Management – ALM)
![]()
![]()
….
Evidemment, dit comme cela, cela peut paraître un peu abrupte voire déconcertant … Cycles de vie des applications – Application Lifecycle Management. Mais sous ce nom se cache en réalité l’une des meilleures pratiques logicielles dont l’objectif est de fournir un logiciel de haute valeur et de haute qualité, et ce d’une manière très efficace, rapide et fiable.
Quelles sont les différentes étapes de l’ALM ?
D’un point de vue du développeur, il est courant de penser que le cycle de vie d’un logiciel commence et s’arrête lors du checkout et du commit des modifications du code.
La réalité est tout autre, comme nous le voyons tous les jours, et couvre beaucoup plus.
Le cycle de vie des applications commence à partir de la création du projet jusqu’à la livraison en production, comprenant plusieurs étapes dont le développement n’est qu’une petite partie parmi, entre autres, les tests, les documentations et la génération d’installateurs.
L’ensemble de ces opérations permet de livrer un logiciel de haute valeur et de haute qualité pour le client.
Ce schéma montre le pipeline de déploiement idéal. On y retrouve l’ensemble des opérations automatisées à mettre en place lorsqu’on parle d’ALM.
Le processus est entièrement automatisé, capable de fournir un feedback détaillé de son statut et de celui de ses opérations, et de s’interrompre à chaque étape en cas de détection d’anomalies.
Bien loin de ce déroulement idéal, le plus souvent, il est fréquent que la plupart de ces opérations soient manuelles, partielles et sans fournir de réel feedback.
Même si maintenant il est largement admis que le code source doit être hébergé dans un outil de contrôle de version, et que chaque développeur doit faire des check-out et commit réguliers, il est encore très rare de trouver une plateforme d’intégration continue réelle automatisée, qui gère ne serait-ce que la compilation automatique et le déroulement des tests unitaires.
A la place, il est fréquent qu’il y ait des flux allant dans toutes les directions, sources de risques et de problèmes à venir, comme le montre le schéma ci-dessous :
Quel est le problème avec la livraison de logiciels ?
- Les opérations sont nombreuses, souvent manuelles et sur différents environnements techniques mal maitrisés,
- Le corollaire est que ces opérations dépendent de quelqu’un (responsable déploiement, chef de projet, expert quelconque). La question est donc : que se passe t’il lorsque cette personne est absente?
- extrêmement répétitives, ces tâches sont une plaie sur le long terme,
- la réalisation d’une documentation souvent lourde est nécessaire,
- une courbe d’apprentissage lente pour l’ajout de nouveaux membres à l’équipe,
- des besoins humains supplémentaires sont nécessaires à l’équipe
- Le code source et les paramétrages ne sont pas nécessairement stockés dans le même endroit, mais peuvent être générés à partir de partout et par n’importe qui, n’importe quand : qui contrôle quoi ?
- Aucune vraie traçabilité,
- Des délais de livraison très long : il peut se passer des jours entre la validation et le déploiement,
- Des erreurs sont plus enclines à apparaître.
En bref : lorsqu’il y a des opérations manuelles, il devient vraiment difficile de répéter, de cadencer et de mesurer la livraison.
Quels sont les objectifs de l’ALM ?
Comme vous l’aurez compris maintenant : implémenter l’ALM c’est principalement se concentrer sur l’automatisation de la grande majorité (sinon la totalité) des opérations ; afin d’assurer la création de valeur et des livraisons fiables, rapides et cadencées.
L’idée maîtresse est de réduire les temps de cycle.
Plus le temps de cycle est court, plus le client pourra être satisfait (par plus de fonctionnalités ou même par des corrections de bugs). L’objectif est de favoriser les feedbacks rapides.
Comment?
Etant donné que cet article est seulement une (très) courte introduction, nous ne plongerons pas plus à fond dans les détails ici.
Nous énumérerons simplement les différents sujets à couvrir. Ceux-ci seront expliqués plus en détails dans de prochains articles :
- Configuration et installation d’un outil d’intégration continue (TFS, Hudson, CruiseControl),
- Mettre au cœur de l’outil l’analyse de qualité (règles de gestion, Sonar, FxCop) ainsi que les tests, le tout avec de l’automatisation,
- Mettre sous contrôle de source tous les paramètres ou fichiers de configuration pour tous les hôtes cibles,
- Lister toutes les autres opérations manuelles, les automatiser et les chaîner entre elles,
- Modifier le processus de développement pour s’appuyer davantage sur les tests d’acceptation,
- Réduire les délais de feedback (testeurs, clients ….).
Conclusion
Cet article n’est que le premier d’une série d’articles introduisant les principes de ALM (intégration continue, déploiement continu…etc). Il vise à présenter simplement ce qui est en jeu tout en abordant les grands principes du cycle de vie des applications.
Dans les prochains articles, nous expliquerons plus en détail avec de cas concrets d’utilisation et d’implémentation, les scénarios de mise en place de l’ALM.
Liens utiles
ALM (sur wikipedia) : pour une explication simplifiée.
Intégration Continue : la définition par M. Martin Fowler
Déploiement Continu : la définition par M. Martin Fowler
Continuous Delivery – Reliable Software Releases Through Build, Test And Deployment Automation : Bible du Continuous Delivery, disponible chez Amazon.
