La livraison continue, ou Continuous Delivery, est une pratique existante depuis de nombreuses années qui tend désormais à se généraliser dans les banques d’investissements et autres institutions financières.

La montée en puissance des clouds privés, du Provisioning As A Service (PAAS) et des démarches DevOps constitue également un contexte technique propice à la mise en place de la livraison continue.

Ainsi, l’implémentation de cette pratique fait partie des projets clés de bon nombre de nos clients.

Il nous apparait donc nécessaire de publier ce premier article afin de clarifier la notion de livraison continue et circonscrire les concepts et méthodologie sur lesquels elle s’appuie.

Qu’est-ce que le continuous delivery ?

Définition du continuous delivery

Continuous Delivery (ou livraison en continu en français) est une stratégie de développement logiciel dans laquelle le logiciel est construit de telle manière qu’il puisse être déployé dans l’environnement de production à tout moment.

Lorsque l’on pratique le continuous delivery, le logiciel est construit de manière itérative avec un cycle le plus court possible de façon à pouvoir livrer des mises à jour fréquentes et incrémentales, au lieu de mettre plusieurs mois à livrer des mises à jour majeures incluant de nombreuses évolutions via des approches « Big bang ».

D’après des indicateurs mis en place par un groupe de travail sur le Continuous Delivery chez ThoughtWorks (source : http://martinfowler.com/bliki/ContinuousDelivery.html), vous faîtes de la livraison continue lorsque :

  • votre logiciel est déployable au travers de son cycle de vie
  • votre équipe se focalise d’abord sur la déployabilité immédiate du logiciel avant de travailler sur les nouvelles fonctionnalités
  • n’importe qui peut obtenir le transfert rapide et automatisé sur la production chaque fois qu’un développeur fait un changement
  • vous pouvez effectuer des déploiements presse-boutons de n’importe quelle version du logiciel sur n’importe quel environnement à la demande

Quels sont les domaines couverts par le continuous delivery ?

Le continuous delivery couvre l’ensemble des domaines de la construction et de la mise à disposition aux utilisateurs d’un logiciel:

  • Le développement de la solution logicielle devant prendre en compte que chaque développement une fois envoyé dans l’outil de gestion de configuration peut être potentiellement déployé en production. Ceci implique un code robuste, donc couvert par des tests automatisés
  • Les tests sur la solution développées qui doivent être automatisés via des outils d’intégration continue pour permettre une livraison à tout moment en production d’une version stable
  • La construction des binaires de la solution et leur déploiement qui doivent être automatisés avec des solutions de déploiement de type « pousse bouton » et des outils d’intégration continue
  • Le versionning du code permettant de générer ces binaires
  • La gestion des infrastructures d’hébergement qui peut être automatisée avec des solutions de type Infrastructure as code
  • La métrologie pour calculer des métriques sur le code (couverture de tests …), mais aussi permettre de monitorer les infrastructures d’hébergement et l’utilisation de la solution logicielle

Pourquoi  travailler en continuous delivery ?

Les apports du continuous delivery sont multiples, et ceci à la fois pour les lignes métier utilisatrices des solutions logicielles, mais aussi pour les membres des équipes IT mettant en œuvre ces solutions.

En effet, du point de vue des utilisateurs finaux des solutions IT, le continuous delivery apporte:

  • Plus de rapidité dans la livraison de solutions répondant à leurs besoins, et donc leur apportant plus rapidement de la valeur

L’automatisation massive que sous-tend le continuous delivery permet de diminuer de manière significative le time-to-market (ie. le temps nécessaire entre l’expression d’un besoin et la mise à disposition d’une solution à ce besoin en production).

D’autre part, avec des outils permettant des déploiements « presse bouton », une version donnée d’un logiciel peut facilement et rapidement être déployée en production.

  • Plus d’adaptabilité des équipes IT par rapport à un besoin métier pouvant évoluer

Ceci permet d’éviter de passer à côté d’une opportunité de marché.

  • Plus de stabilité et de robustesse du logiciel et du processus de livraison

L’automatisation des tests dans la chaîne de continuous delivery donne un feedback rapide aux équipes de développement lorsqu’une régression est introduite.

Le processus de livraison étant lui aussi automatisé, il est reproductible et donc plus robuste.

  • Moins de coûts de maintenance découlant d’une stabilité plus importante
  • Des équipes IT pouvant mettre le focus sur le développement et le déploiement de fonctionnalités apportant le plus de valeur aux utilisateurs du fait que les coûts de maintenance (correction de bugs, livraisons manuelles) sont réduits
  • Plus de visibilité sur le produit logiciel et donc une appropriation simplifiée de la solution, ceci grâce à des livraisons fréquentes et incrémentales

Le continuous delivery permet donc d’avoir des utilisateurs satisfaits.

Du point de vue des équipes IT développant les solutions et gérant les infrastructures d’hébergement de ces solutions, le continuous delivery apporte :

  • Moins de coûts d’exécution et d’infrastructure grâce à l’automatisation de la construction d’environnements Cloud
  • Plus de prédictibilité sur les livraisons (date, niveau de confiance …) grâce à une stabilité de la solution améliorée
  • Moins de stress lors des déploiements en production
  • Plus de collaboration entre les développeurs et les opérationnels gérant les infrastructures et les déploiements du fait qu’une plateforme de continuous delivery intègre les phases de développement et de déploiement et que ces deux parties communiquent via l’automatisation des étapes.
  • Des décisions factuelles et non empiriques au bon vouloir des utilisateurs

Grâce aux outils de métrologie d’une plateforme de continuous delivery, il est tout à fait possible de monitorer l’utilisation d’une solution logicielle et d’en extraire des décisions basées sur des mesures (ex : retirer une fonctionnalité non utilisée pour éviter de la maintenir inutilement)

Le continuous delivery permet donc aussi d’avoir des équipes IT satisfaites de leur travail.

Continuous delivery et les concepts adjacents

Continuous delivery et Continous deployment

On confond souvent continuous delivery (livraison en continue en français) et continuous deployment (déploiement en continu).

Comme indiqué sur le schéma ci-dessous (Source : http://blog.crisp.se/2013/02/05/yassalsundman/continuous-delivery-vs-continuous-deployment), la différence entre ces deux concepts concerne la phase de déploiement en production.

Continuous delivery-deployment

Dans le continuous deployment, toute modification sur le code est déployée automatiquement sur l’environnement de production après avoir été bien sûr validée par l’ensemble des tests automatisés. Ce déploiement n’implique aucune décision humaine.

Dans le continuous delivery, toute modification sur le code peut être déployée sur l’environnement de production, mais ne l’est pas forcément. Une décision humaine intervient avant tout déploiement en production. Ce déploiement peut toutefois être automatisé par des outils une fois cette décision humaine prise.

Le continuous deployment va donc un peu plus loin que le continuous delivery.

Continuous delivery et Continuous integration

Le continuous integration (ou intégration continue en français) est un ensemble de pratiques utilisées en génie logiciel consistant à vérifier à chaque modification de code source que le résultat des modifications ne produit pas de régression dans l’application développée, et à assembler les binaires de la solution (phase de « build »). Ce concept est issu de l’extreme programming.

Le principal but de cette pratique est de détecter les problèmes d’intégration au plus tôt lors du développement. De plus, elle permet d’automatiser l’exécution des suites de tests.

Au vu de cette définition, il semble clair que l’intégration continue est une base minimale au continuous delivery. Ce dernier se fonde sur l’intégration continue et y ajoute les étapes finales nécessaires pour le déploiement sur les différents environnements, de production ou pas.

Pour conclure, on constate que le continuous delivery s’implante progressivement chez nos clients depuis deux à trois ans. Dans certains établissements financiers, aujourd’hui, la mise en place de cette pratique s’intensifie au point de devenir un standard, un must to have pour tout nouveau projet.

En effet, dans un contexte où la réactivité devient primordiale pour avoir un avantage concurrentiel ou répondre toujours plus rapidement à des contraintes réglementaires, ces entreprises se sont rendues compte que le continuous delivery pouvait être une composante essentielle pour pouvoir livrer rapidement, en continu et de manière plus fiable de la valeur aux lignes métier.

Nous espérons que ce premier article a fait découvrir ou rendre plus claire la pratique de continuous delivery à ceux qui ne la connaissaient pas ou peu.

D’autres articles sur cette thématique seront publiés sur ce blog, à commencer par un billet sur la mise en place d’une approche continuous delivery qui fera un focus sur les pratiques et l’outillage. Des surprises viendront par la suite qui, nous l’espérons, vous plairont.

Enfin, si vous souhaitez que l’on aborde un sujet lié au continuous delivery, continuous integration, n’hésitez pas à laisser vos propositions dans les commentaires de cet article ou sur nos pages twitter !

A bientôt