La continuous delivery est en train de remplacer l’ALM : pourquoi et comment ?

La gestion du cycle de vie des applications (ALM) est un processus vertical qui a été mal vécu par les développeurs, les testeurs et le personnel informatique qui ont été forcés à l’utiliser. Issue des pratiques de fabrication industrielle, comme les logiciels de gestion du cycle de vie des produits (PLM), l’ALM n’a jamais été un choix naturel pour l’industrie logicielle et, récemment, des processus comme le déploiement continu ont commencé à éclipser les pratiques et outils d’ALM traditionnels. Cet article s’intéresse aux facteurs de croissance du déploiement continu et aux raisons pour lesquelles vous devriez l’adopter.

Livraison en cascade et silos : processus et pratiques d’ALM

L’ALM concerne les étapes de planification, de conception, de mise en œuvre, de test, de livraison et de maintenance du cycle de vie d’une application. Examinons le processus d’ALM et les outils utilisés pour le faire fonctionner.

Le processus d’ALM

Chaque étape du processus d’ALM est effectuée dans l’ordre par des équipes différentes suivant le modèle de développement en cascade. Dans les grandes organisations, ce processus est souvent initié par les analystes qui identifient un besoin pour un produit ou service précis. Les analystes rassemblent les exigences métier, qui sont ensuite transmises à l’équipe de conception et traduites en exigences fonctionnelles qui seront utilisées pour concevoir une architecture système et des spécifications. Une fois achevé, le concept est confié à une équipe de développement chargée d’écrire le code et de mettre en œuvre le concept. Une fois le code écrit et l’application créée, le projet entre en phase de test, puis l’application est transmise à l’équipe de déploiement pour être publiée.

À ce stade, nous pouvons déjà observer un certain nombre de problèmes courants associés à la mise en œuvre du processus d’ALM. Pour commencer, ce processus est basé sur un modèle de chaîne logistique ou de ligne de production qui suppose que la livraison des éléments-clés respectera des délais stricts. Toute personne impliquée dans le processus de développement logiciel comprend que rien n’est jamais livré à temps et qu’il y a toujours des retards. Pour couronner le tout, le processus d’ALM repose sur des équipes spécialisées qui doivent gérer chaque étape. Idéalement, le processus devrait être horizontal, avec des informations et des livrables qui circulent d’un groupe à l’autre. Mais avec le temps, les équipes individuelles d’analystes, de concepteurs, de développeurs et de testeurs compartimentent leurs efforts et forment des silos verticaux. Les équipes ne communiquent pas entre elles et conçoivent souvent une certaine hostilité les unes à l’égard des autres.

Outils d’ALM

Un moyen courant de surmonter les problèmes inhérents à l’ALM consiste à créer ou acheter des outils. Cependant, cela entraîne souvent un certain nombre de nouveaux problèmes, en particulier lorsque les organisations font un choix entre des systèmes d’élite et des systèmes intégrés pour leur solution d’ALM.

L’approche élitiste repose sur l’hypothèse selon laquelle vous devriez pouvoir choisir le meilleur produit dans la catégorie ou sous-catégorie pour laquelle il est prévu. En théorie, cette approche devrait résulter en un système dans lequel la somme des éléments excède la valeur des éléments individuels. En pratique, cela se produit rarement, car il est toujours difficile et frustrant d’intégrer des produits provenant de fournisseurs différents. Dans l’industrie logicielle, il est courant de passer par une période de consolidation durant laquelle les petits fournisseurs sont rachetés par l’acteur dominant du secteur. En théorie, cela devrait permettre de choisir des produits d’élite auprès d’un fournisseur unique assurant l’intégration, la maintenance et l’assistance de chaque item de son portefeuille vaste et croissant. Malheureusement, ce résultat, bien que possible, est extrêmement rare en réalité.

Un système d’ALM intégré s’efforce de fournir l’ensemble des éléments clés du processus d’ALM dans un seul package, permettant ainsi aux utilisateurs de gérer les spécifications, les tests et les défauts à partir d’un produit unique. Cependant, l’approche intégrée illustre l’expression « touche-à-tout et bon à rien ». Par exemple, si le produit a été développé par une société spécialisée dans les outils de test logiciel, il est fort probable que le module de gestion des tests soit bien meilleur que les modules de gestion des spécifications et des défauts. Par conséquent, les utilisateurs doivent choisir le moindre de deux maux : essayer de travailler avec des outils inférieurs fournis par leur éditeur préféré ou intégrer des outils supplémentaires fournis par des tiers. Cela signifie qu’une organisation qui opte pour une approche intégrée se retrouve en fait avec une solution élitiste.

Le tout continu : intégration, livraison et déploiement

Ces vingt dernières années, une approche basique très différente a évolué pour gérer le processus de développement logiciel. À la suite de la publication du Manifeste Agile, la communauté des développeurs a mis au point un certain nombre de nouvelles méthodologies et pratiques. Il s’agit notamment d’Agile, des DevOps, du lean startup, de l’open source et du développement piloté par les tests. Parallèlement, de nouvelles technologies web (ou dans le cloud) comme Git, GitHub, la gestion des paquets, l’automatisation des tests, les machines virtuelles et les conteneurs ont modifié la façon de développer des logiciels. Avec le temps, ces développements ont mené à de nouvelles façons d’intégrer et de livrer des logiciels en continu, pour aboutir à la livraison et au déploiement continus.

La livraison continue, ou continuous delivery, s’appuie sur l’intégration continue pour réduire l’intervalle entre l’écriture du code source d’une application et le déploiement effectif de ce code auprès des utilisateurs de tout produit et/ou service reposant sur un logiciel. Pour atteindre cet objectif, il faut construire un « pipeline de livraison » fournissant toute l’infrastructure nécessaire pour créer, tester, publier et déployer des logiciels en production très fréquemment. De nombreux adeptes du déploiement continu créent et mettent à jour le code en production plusieurs fois par jour. Pour y parvenir, le processus s’appuie sur l’intégration des logiciels open source de test, de gestion des versions, de création et de déploiement pour créer un processus fortement automatisé et efficace.

En général, les processus continus (intégration, livraison et déploiement) ont produit des résultats plus constants et plus satisfaisants que les processus basés sur l’ALM. L’une des principales raisons de l’adoption généralisée de ces nouvelles pratiques est l’acceptation globale du développement agile. Agile n’est plus un mouvement marginal controversé : c’est devenu un courant dominant. Ses adeptes se trouvent aussi bien dans les plus petites start-ups que dans de grandes entreprises, et même, dans certains cas, dans le secteur gouvernemental. À présent que les pratiques agiles sont largement acceptées, les développeurs ont créé des outils basés sur les idées d’Agile. Nombre de ces outils ont été créés et maintenus par les personnes qui les utilisent au quotidien, ce qui facilite à la fois leur extension et leur intégration à d’autres outils open source.

Avec le temps, ces outils ont mûri et sont devenus les composants de base du développement d’application moderne. Par conséquent, les développeurs peuvent aujourd’hui se concentrer sur la livraison de produits et la production de résultats au lieu de s’occuper de processus complexes. Et les clients et utilisateurs obtiennent non seulement de nouveaux produits et fonctionnalités, mais aussi la capacité à faire des retours presque en temps réel. Cela signifie que, lorsqu’un utilisateur découvre un problème dans une application et en informe les développeurs, ces derniers peuvent résoudre le problème et publier une nouvelle version améliorée du produit plus vite que jamais.

Livrer des améliorations en continu

À bien des égards, l’ALM était une tentative de dompter le processus de développement en essayant de le contrôler totalement. Une méthode visant à affirmer ce contrôle consistait à rassembler les spécifications et à s’assurer que la mise en œuvre finale les remplissait. Une autre méthode clé demandait aux chefs de projet de prendre constamment le pouls d’un projet en définissant un éventail de métriques et en suivant les indicateurs de performances clés (KPI).

Dans le monde agile d’aujourd’hui, la gestion des spécifications et des indicateurs est grandement tombée en désuétude, mais ces deux domaines conservent une importance vitale pour la création et la livraison de logiciels de qualité. Pour réussir, une application ou un service doit toujours répondre aux exigences de ses utilisateurs. De plus, la chaîne de livraison employée pour créer des applications modernes est fortement automatisée et nécessite de l’instrumentation, c’est-à-dire un suivi et des indicateurs. C’est là qu’une solution de livraison agile en entreprise (EAD) comme Release Dynamix (RDx) de Panaya peut vous aider. RDx vous permet de gérer les spécifications et de contrôler l’ensemble du processus de livraison à l’aide de méthodes agiles et d’outils continus DevOps pour produire d’excellents logiciels.

Résumé : combiner le meilleur des deux mondes

L’ALM était peut-être une méthodologie imparfaite qui, dans le meilleur des cas, produisait des résultats mitigés, mais c’était une tentative de mettre de l’ordre dans le chaos qui dominait à l’époque la gestion des projets de développement logiciel. Cet article a démontré que les processus d’ALM exacerbaient les problèmes existants, comme la rupture des communications et la compartimentation, et que de nombreuses organisations essayaient de surmonter les aspects complexes de l’ALM à l’aide d’outils onéreux et complexes. Dans les deux cas, ni les processus ni les outils n’ont amélioré les choses, et dans de nombreux cas, ils les ont même fait empirer.

Aujourd’hui, nous vivons dans un monde nouveau d’intégration, de livraison et de déploiement continus, où les processus DevOps sont considérés comme la concrétisation finale du mouvement agile. Pourtant, nous pouvons tirer des leçons de l’ALM qui pourraient être utiles aux équipes et aux organisations lorsqu’elles mettent en œuvre des processus continus et en étendent l’utilisation. En adoptant de nouveaux systèmes comme la livraison agile en entreprise et de nouveaux outils comme Release Dynamix de Panaya, vous pouvez combiner le meilleur des deux mondes afin de créer des applications novatrices et de qualité supérieure.

Pour en savoir plus sur la façon dont les méthodes Agile et DevOps favorisent la réussite et sur certaines des bonnes pratiques à adopter en matière de livraison agile en entreprise, lisez le rapport gratuit de Forrester, The State of Agile 2017: Agile at Scale.