Ingénierie des méthodes Agiles : Que cache l opposition entre déploiement et livraison en continu? Faut-il adopter DevOps 1?

Transcription

1 DEVOPS et le déploiement d application Les Livres Blancs de MARTE Ingénierie des méthodes Agiles : Que cache l opposition entre déploiement et livraison en continu? Faut-il adopter DevOps 1? L alignement du SI sur les attentes du métier se pilote à moyen et à court terme : La gestion de moyen terme repose sur l utilisation d un portefeuille de projets qui agrège les demandes du métier selon leur priorité. Les méthodes agiles prennent en charge la réactivité de la phase de développement proprement dite. Mais faut-il aller jusqu aux mises en production en continu ou bien rejoindre les partisans des livraisons en continu et du déploiement par lot comme le suggère Jez Humble 2? Que cache finalement ce débat sur le déploiement d application? Nous allons voir que 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 maigre et performante. Celle-ci repose sur quatre piliers : le développement en parallèle agile, la gestion de configuration logicielle de déploiement, la gestion versionnée des paramètres de configuration et l automatisation des déploiements applicatifs Livre blanc rédigé par Alain Sacquet Juin DevOps est la contraction de DEVeloppement et OPErations, terme anglais pour la production. DevOps vise la transformation des relations entre ces deux entités dans le but de réduire le délai de mise en ligne des fonctionnalités. 2 Jez Humble 2

2 Ingénierie des méthodes Agiles : Que cache l opposition entre déploiement et livraison en continu? 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 adaptes 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 fonctionnements bien distincts dont le plus abouti représente une solution très pertinente pour de nombreuses DSI. Les méthodes agiles Les principes regroupés sous le thème des méthodes de développement agiles sont bien connus : priorisation des fonctionnalités à développer par sprint de quelques jours, implication et disponibilité du client dans la description progressive du détail de ses attentes, consolidation du travail de chaque membre de l équipe par des techniques d intégration continue et de tests rigoureux. 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 2 Décembre 2013

3 logiciel qui est 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. LE MÉCANISME D INTÉGRATION CONTINUE Quelle ingénierie pour la DSI agile? Dév Int Dév Int Dév Int Dév Int DEV INT PROD 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 Ce mode d organisation des développements n est pas réellement nouveau mais 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 logiciel conforme à ces principes. L intégration continue repose ainsi sur l intégration sans couture des éditeurs de sources, des outils de 1 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 à la main 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? 3 Juin 2014

4 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 dispense du développement en parallèle et des reports de corrections. La mise en production par lot nécessite donc une organisation et une ingénierie plus puissantes. 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. Le meilleur des deux mondes 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. Quelle ingénierie pour la DSI agile? L EXTENSION DU MÉCANISME D INTÉGRATION CONTINUE AU DÉVELOPPEMENT EN PARALLÈLE AGILE Dév Int Dév Int DEV INT PROD Le développement en parallèle agile Mise en production de la release 1 Mise en production de la release 2 DEV INT PROD DEV INT PROD DEV INT PROD 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. 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 d une correction urgente, sont identifiés et leur mise à jour dans le projet le plus lent devient indispensable avant la 2 4 Juin 2014

5 fabrication d une nouvelle version de l application. Ce principe est le pendant de celui imposé par l intégration continu 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 au moment de 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 Logiciel 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 qualité 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 subrepticement 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 alors 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 et l 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 l automatisation des installations. 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 5 Juin 2014

6 aujourd hui une énergie considérable à faire manuellement les mises en production des paliers majeurs qui succèdent, sans capitalisation, aux installations effectuées dans les environnements de qualification! Reprenons. Les méthodes agiles améliorent la réactivité de développement de la DSI. Elles reposent sur des technologies et des chaînes de fabrication permettant l intégration continue des logiciels et leur déploiement automatique. Ce processus qui met plus rapidement les fonctionnalités à disposition des utilisateurs est né chez les sociétés internet «pure player». Il correspond à leur modèle d affaire et à sa gouvernance. Cette performance s obtient par une cohérence technologique et un investissement dans l outillage de l ingénierie. Les DSI doivent-elles adopter DevOps, l automatisation des déploiements, ou ne rien faire? Les entreprises plus classiques ont-elles intérêt à adopter cette innovation? Répondre à cette question suppose la revue par les parties prenantes des enjeux de la réactivité du déploiement des nouvelles fonctionnalités de chaque application, mais aussi l évaluation de l intérêt de sécuriser par l outillage les mises en production des paliers complets utilisés pour homologuer les applications fortement intégrées fonctionnellement. Plutôt que de porter sur la fréquence des mises en production, le choix d entreprise porte en fait sur le niveau de gamme de l ingénierie de la DSI : faut-il privilégier une ingénierie «d entrée de gamme» basée sur l externalisation des tâches manuelles et la tolérance aux incidents ou investir sur son ingénierie quitte à la faire reposer sur des logiciels libres pour en diminuer le coût? C est à nouveau l automatisation des déploiements et non l augmentation de leur fréquence qui confère à DevOps son caractère innovant dans la répartition des tâches entre les études et la production. Une fois automatisée, ces tâches habituellement réalisées par la production ne sont plus un enjeu de territoire. L automatisation de la surveillance permanente de la bonne santé des processus d affaire automatisés (Business Activity Monitoring) a la même vertu. L automatisation apaise les tensions organisationnelles et appelle à repenser les missions. Notons que l automatisation des installations récurrentes rend plus autonome les études et contribue ainsi à l utilisation d infrastructures proposées en mode Cloud. Au-delà du débat médiatique sur DevOps, l industrialisation possible des déploiements amène à nouveau les DSI à réfléchir sur les transformations de leur mode de production. Une ingénierie de haut de gamme est en effet de nature à améliorer l alignement sur les besoins des 6 Juin 2014

7 métiers, la performance de la DSI et la gestion de ses ressources. L ingénierie idéale d une DSI «lean» L ingénierie idéale pour une DSI à laquelle on demande efficience et réactivité est donc celle qui soutient les méthodes de développements parallèles agiles après que la gestion du portefeuille des projets a décidé d engager les développements. Les fonctionnalités sont livrées jusqu à la production et déployées immédiatement, si les parties prenantes ont retenu ce choix, ou bien mises en production automatiquement par lot, avec d autres applications, à l occasion d un même palier. Si vous désirez télécharger la suite de ce livre blanc, cliquez sur ce lien. 7 Juin 2014

8 A propos de MARTE Conseil Les DSI améliorent sans cesse leur performance opérationnelle au service des métiers et adaptent sans relâche leur fonctionnement. MARTE accompagne ces évolutions par des interventions de conseil et d expertise permettant de transformer en mode service, d optimiser ou d opérer les processus clé de l ingénierie : gestion de projets ingénierie des développements et framework gestion des déploiements et des configurations logicielles les processus d IT Service Management Vous pouvez aussi bénéficier auprès du cabinet MARTE Conseil de diverses prestations de cadrage, de pilotage et de mise en œuvre de vos projets de constitution de centres d intégration, de qualification et de test. MARTE Conseil intervient également dans le domaine de l architecture d entreprise et de la gouvernance du SI : Architecture d entreprise : Cadrage, mise en œuvre et fonctionnement de Centres de Services d Architecture d Entreprise Externalisation : Prestation de tierce partie et d AMOA pour l externalisation ou le repositionnement de votre recours à la sous-traitance Business Activity Monitoring : Solutions de suivi de l activité en production des processus d affaire critiques du point de vue des métiers, qu ils prennent la forme de traitements événementiels, de traitements par lot ou de solutions hybrides Gouvernance : pilotage budgétaire, gestion de portefeuille de projet, pilotage de programme, organisation de la DSI La complémentarité des consultants en système d information et des directeurs de projets techniques permet à MARTE de vous apporter des solutions intégrées depuis la recommandation jusqu à la mise en œuvre, dans le cadre de prestations classiques ou à travers la constitution de centres de services de transformation. La déontologie et l indépendance de MARTE vous assurent une prestation sans biais. Contact MARTE Conseil 7, rue des Huissiers, Neuilly Téléphone : Site Web : 8 Décembre 2013