Tribunes

Ingénierie des méthodes agiles : que cache l'opposition entre déploiement et livraison en continu ?

Il existe deux grands modes de développement agile : d'un côté le déploiement en continu et, de l'autre, la livraison en continu, prolongée par un déploiement par lot. L'opposition absolue des deux n'est pas forcément pertinente.

PublicitéLes méthodes de développement agiles constituent un indéniable progrès dans la conduite des projets informatiques. L'actualité est aujourd'hui portée par la vague Devops qui met l'accent sur l'automatisation des déploiements.
C'est l'occasion d'un débat entre les adeptes du déploiement en continu et ceux de la livraison en continu, prolongée par un déploiement par lot. Ce sujet cache un choix entre deux modes de fonctionnement bien distincts, dont le plus abouti représente une solution très pertinente pour de nombreuses DSI.
Le modèle des développements agiles, prolongé par la livraison continu et son corollaire, la mise en production par lot des applications, fournit la solution idéale pour une DSI. Celle-ci repose sur quatre piliers :
- le développement en parallèle agile,
- la gestion de configuration logicielle de déploiement,
- la gestion des paramètres de configuration,
- l'automatisation des déploiements applicatifs.

Les principes de l'intégration continue

Les règles de l'intégration continue imposent, au sein d'un sprint, que chaque développeur prenne en compte les évolutions apportées par les autres membres de l'équipe avant de publier ses propres améliorations. Dans l'intervalle, il peut choisir d'intégrer les évolutions publiées à la fréquence qui lui convient. Ces publications déclenchent la fabrication d'une nouvelle version complète du logiciel mise à disposition dans un environnement de test collectif.
La symétrie de ce mécanisme cadencé par le sprint est la source de la productivité qu'apporte l'intégration continue : elle organise l'ajustement réciproque des évolutions par les différents membres de l'équipe. L'application refabriquée automatiquement est tout d'abord incorrecte, du fait des contributions simultanées de chaque développeur, puis les défauts mis en évidence sont progressivement corrigés dans le temps du sprint.
Ce mode d'organisation des développements n'est pas réellement nouveau. Il s'appuie désormais dans le monde Java, sur un ensemble d'outils open source qui composent aisément une chaîne de construction de logiciels conforme à ces principes. L'intégration continue repose ainsi sur l'intégration « sans couture » des éditeurs de sources, des outils de gestion de version, de fabrication d'exécutables et de déploiement automatique.

Déploiement ou livraison en continu ?

La fin du cycle de développement, à savoir la mise en production, demeure moins consensuelle. Quelques tensions s'expriment ainsi dans l'univers agile, entre les partisans du déploiement en continu et ceux de la livraison en continu. Les premiers souhaitent que chaque sprint donne lieu à mise en production. Les seconds s'accommodent d'une livraison continue jusqu'en production, mais souhaitent un déploiement effectif ou une activation finale à l'initiative des métiers.
En effet, sauf exception, ceux-ci ne souhaitent guère être confrontés à des modifications incessantes et n'entendent pas subir les montées de version. Plusieurs livraisons successives de la même équipe donnent alors lieu à une seule mise en production. Les déploiements sont tirés par le métier et non poussés par les informaticiens.
Que cache cette opposition ? Pourquoi les tenants du déploiement en continu s'arcqueboutent-ils sur le déploiement de chaque sprint ?
La raison invoquée est une complication inutile : à quoi bon ne pas fournir aux utilisateurs ce qui est disponible, et pourquoi distinguer des fabrications destinées à aller en production et des builds jetables, au risque implicite de démobiliser l'équipe de développement ?

PublicitéLivraison en continu et développement en parallèle

Livraison en continu et développement en parallèle

La complication est en fait ailleurs et il faut aller chercher un peu plus loin la raison de ce manque apparent de pragmatisme : dès lors que les mises en production s'espacent, le temps de développement complet d'une nouvelle version de l'application s'allonge et la possibilité d'embarquer les correctifs urgents dans le flux continu des modifications s'éloigne. Un couloir de maintenance urgente se réouvre. Seule la mise en production rapide des développements continus dispense du développement en parallèle et des reports de corrections.
L'opposition entre déploiement ou livraison en continu peut être dépassée. Il suffit pour cela que l'ingénierie des méthodes agile intègre le développement en parallèle Un complément d'outillage reposant sur la gestion de configuration logicielle permet de disposer du meilleur des deux mondes pour les développeurs et le métier. Les atouts de l'intégration continue sont maintenus pour le développement de chaque release et trois fonctionnalités majeures sont ajoutées.
La première fonctionnalité porte sur la phase de développement elle-même.

Le développement en parallèle agile
La caractéristique d'une correction urgente est qu'elle double le projet de développement : commencée après lui, elle ira en production avant. De même, des évolutions prévues pour aller en production, au titre de deux releases planifiées à des dates distinctes, voient parfois leur ordre d'arrivée en production inversé.
Le développement en parallèle agile facilite ce mode de fonctionnement. Chaque release est protégée des modifications faites dans un autre couloir de développement que le sien. Les composants modifiés en parallèle au titre des deux projets, ou du fait de la correction urgente, sont identifiés et leur mise à jour, dans le projet le plus lent, est indispensable avant la fabrication d'une nouvelle version de l'application.
Ce principe est le pendant de celui imposé par l'intégration continue au sein d'un même projet, lorsqu'un développeur doit tout d'abord intégrer les nouveautés publiées par les autres membres de son équipe, lorsqu'il souhaite promouvoir ses propres modifications.
Les mécanismes techniques correspondants étendent la solution d'intégration continue au développement en parallèle agile tout en s'appuyant sur les outils open source de gestion de version.

La gestion de configuration logicielle de déploiement
La seconde fonctionnalité porte sur la gestion de configuration logicielle de déploiement.
La mise en production par lot, propre aux livraisons continues, induit la gestion en configuration des livraisons projets. L'ingénierie agile consiste à maîtriser le dernier build d'une application pour chacun des lots planifiés de mise en production, mais aussi les derniers builds des autres applications qui iront en production simultanément.
La cohérence fonctionnelle de chacune de ces releases doit être assurée pour permettre aux métiers de décider les mises en production sur la base des changements validés. La cohérence technique du lot permet, à son tour, d'éviter qu'une même release contienne des versions différentes de composants. Cette fonctionnalité couvre le processus Itil release management and deployment.

La gestion des paramètres fonctionnels et techniques
La gestion de configuration logicielle des déploiements accueille naturellement les différents paramètres fonctionnels et techniques nécessaires aux installations automatiques. La gestion des versions successives de ces paramètres de configuration, leur confidentialité, la prise en compte des variantes par environnements, la distinction des paramétrages fonctionnels (adresse mail d'envoi de messages fonctionnels) et techniques (certificat, paramétrage de configuration...), aux cycles de vie différents, est une activité délicate et très consommatrice de ressources en l'absence d'un outillage dédié. Leur bonne gestion est cependant indispensable à l'automatisation des déploiements, source majeure de l'agilité.

DevOps, gouvernance et automatisation des déploiements

DevOps, gouvernance et automatisation des déploiements

On sait que les déploiements en continu imposent la livraison en continu et que l'inverse n'est pas vrai. De même, le déploiement en continu impose son automatisation. La mise en production par lot dispense-t-elle, par contre, de cette industrialisation ? La réponse est manifestement positive, puisque les DSI dépensent aujourd'hui une énergie considérable à réaliser manuellement les mises en production des paliers majeurs, qui succèdent aux installations dans les environnements de qualification.
De même que les méthodes agiles ne dispensent pas la gouvernance du SI de décider, avec l'ensemble des parties prenantes, de la fréquence des changements du système en production, application par application, le maintien de la mise en production par palier de plusieurs applications interconnectées n'affranchit pas davantage la même gouvernance d'une réflexion sur l'intérêt d'automatiser les déploiements, qui nécessitent aujourd'hui de nombreuses tâches manuelles taylorisées, aussi risquées et coûteuses que peu valorisantes pour ceux qui les exécutent. Ce sujet est ainsi probablement, aujourd'hui, un des meilleurs investissements que peut réaliser une DSI.

Quelle ingénierie idéale ?

L'ingénierie idéale pour une DSI lean et réactive est donc celle qui soutient les méthodes de développements parallèles agiles, après que la gestion du portefeuille des projets a rendu son verdict. Les fonctionnalités déployables sont livrées jusqu'à la production et déployées immédiatement, si les parties prenantes ont retenu ce choix, ou mises en production automatiquement par lot, avec d'autres applications, à l'occasion d'un même palier.
La solution de développement en parallèle agile est propice à une mise en oeuvre souple : il est ainsi possible de panacher le déploiement en continu de l'application dans l'environnement de test projet, avec un déploiement par lot à destination des environnements de production.
De même, les reports de maintenance à chaud ou de développement en parallèle peuvent n'être rendus bloquants que pour les étapes ultimes du développement. Enfin, certaines applications peuvent être systématiquement gérées en déploiement continu.
La gestion de la configuration logicielle de déploiement aux deux visages gère l'aboutissement des sprints pour les développeurs et la Definitive Software Library, chère à Itil pour la production. Elle renoue ainsi le lien entre études et production, comme le souhaite l'approche DevOps.
La gestion de la configuration logicielle de déploiement est aussi l'occasion de classer les livraisons continues des projets conformément au découpage applicatif retenu par les architectes d'entreprise. Du point de vue de la gouvernance, ce point de passage obligé dès les étapes de qualification fournit des informations objectives sur l'avancement des projets et l'activité de développement. Le classement des livraisons projets s'effectue également par technologie. La gestion de la configuration logicielle de déploiement, complétée par la gestion des paramètres de configuration permet alors l'automatisation des déploiements.
En synthèse, la tension entre les partisans du déploiement en continu et les tenants de la livraison en continu manifeste le besoin réel de franchir un dernier palier vers le développement en parallèle agile. Complétée par les gestions de configuration de déploiement, la livraison continue apparaît comme le modèle abouti des méthodes agiles, ne serait-ce que parce que le déploiement en continu n'est que le cas particulier du déploiement par lot, lorsque le lot correspond au sprint.

Article rédigé par

Alain Sacquet, Consultant et auteur
Alain Sacquet est ingénieur de l'école Centrale Lille et a consacré sa carrière à la direction de programmes et à l'architecture d'entreprise. Il crée avec Jérôme Gautier le cabinet Marte Conseil en 2000 pour combiner les meilleures expertises de transformation organisationnelle et de management avec l'ingénierie la plus pointue. Il travaille aujourd'hui chez Timspirit.

Alain Sacquet est l'auteur de « Mettre en oeuvre DevOps » publié chez Dunod.