Livraisons logicielles : en finir avec "l’effet du lundi matin"

Mieux communiquer entre développeurs et opérationnels, automatiser radicalement le processus: deux clés d’un déploiement efficace des nouveautés logicielles.

Mieux communiquer entre développeurs et opérationnels,  automatiser radicalement le processus: deux clés d’un déploiement efficace des nouveautés logicielles

« En matière de déploiement, l’effet du lundi matin est courant, explique Erick Minick de Urban Code, une entreprise IBM  fournissant des outils automatisant les livraisons logicielles. Les mises à jour ont en effet tendance à être effectuées le week-end. « Le lundi chacun, y compris l’équipe de développement, épuisée, s’affaire à éteindre les incendies qui se révèlent. Puis l’équipe de déploiement peut souffler et les autres acteurs commencent (prudemment) à utiliser les systèmes.  Je me souviens d’une preuve de concepts que nous organisions avec un futur client, en lui suggérant de démarrer un lundi.  « Pourquoi pas mardi ? », nous proposa-t-il, « nous avons une grosse mise à jour pendant le week-end… »
Les racines de cet effet sont rappelées dans un livre blanc récent d’IBM ; mauvaise communication, conflits et goulet d’étranglement entre équipes de développement et opérationnelles, car souvent leurs objectifs ne sont pas alignés. On peut également citer les applications présentant de fortes interdépendances ou encore la coexistence de processus et d’outils différents, sources d’incohérences et d’erreurs. Qui plus est, l’essor des processus agiles, accélérant le rythme de création et de livraison, tend à aggraver toutes ces tensions. Des  problèmes d’autant plus inacceptables que les entreprises, en se tournant vers les pratiques agiles et « Lean » pour concrétiser leur attention accrue aux exigences client, montrent bien à quel point elles misent désormais aussi sur le logiciel dans leur stratégie.
Selon le document IBM,  ce constat est valable pour les entreprises bien établies, aux produits généralement plus stables, comme pour les entreprises plus jeunes. On aurait pu penser que ces dernières, plus flexibles, ont plus d’atouts pour déployer les codes à un rythme soutenu, corriger les bugs et réagir rapidement aux tendances du marché. Ce constat évolue et beaucoup d’entreprises améliorent leurs processus. Le Livre banc cite une entreprise du secteur du divertissement « passant d’une livraison bi-hebdomadaire, devant être programmée longtemps à l’avance, à des déploiements en production à la demande, simplement en mettant en œuvre un solution automatisée ». Dans tous les cas, préconise le Livre Blanc IBM la réactivité des fonctionnalités doit aller de pair avec un déploiement continu et sans faille du logiciel, grâce à une stratégie personnalisée d’automatisation.

Rapprocher les équipes autour d’une culture de l’automatisation

Comment garantir des livraisons fréquentes et « sans couture » ? IBM y répond en proposant son approche de gouvernance et d’automatisation DevOps. Les problèmes étant très imbriqués, la livraison et le déploiement continus y sont pensés de façon intégrée avec tous les autres aspects,  comme la planification métier, le développement collaboratif, la surveillance et l’optimisation continues. Miser sur l’automatisation complète des livraisons, avec des outils tels qu’Urban Code qui s’intègrent dans DevOps,  amène à corriger et unifier le processus, tout au long du cycle de vie de livraison, en l’examinant pas à pas en environnement de production. Cela représente  un  effort initial important, aboutissant à mettre en place avec soin un processus de déploiement planifié, testé des dizaines de fois, avec une visibilité de bout en bout. Mais cet effort initial est ensuite la clé du succès : il ne garantit pas seulement une automatisation totale, assurant la reproductibilité du processus à la demande. Il permet aussi de construire l’accord des équipes autour d’une vision détaillée et partagée du processus, bien en amont de l’exécution en production. « L’effet du lundi matin »…, bientôt un mauvais souvenir ?

Pour approfondir sur Middleware et intégration de données

Close