Le métier du développeur évolue en profondeur comme nous l’avons évoqué récemment. Pour répondre aux nouveaux défis posés par les transformations du monde de l’IT, ainsi qu’aux besoins croissants de leurs clients, les développeurs doivent se doter d’outils de Continuous Delivery.

Aujourd’hui, nous revenons donc sur les apports du Continuous Delivery pour le développement applicatif. Si les méthodes agiles contribuent à obtenir un retour d’information régulier de ses clients et utilisateurs, le Continuous Delivery permet d’obtenir du feedback technique de l’état de son application.

Quelques minutes après un commit, j’obtiens la garantie que je n’ai pas introduit de régressions dans mon application et que l’ensemble est livrable en production. Et si ce n’est pas le cas, j’obtiens la liste des tests que j’ai cassés avant de commencer à travailler sur autre chose, ce qui évite de revenir plus tard sur le sujet. Mettre en place une démarche de Continuous Delivery permet donc d’avoir un feedback très rapide et régulier sur l’état du code à l’instant T.

Quel intérêt pour le client ?

Pour le client, l’intérêt facilement mesurable. L’automatisation de toutes les étapes permettant d’aller de la compilation à la mise en production conduit à une réduction du coût unitaire de mise en production. Concrètement, pour l’utilisateur du service, cela signifie des mises en production plus fiables et plus fréquentes. On améliore ainsi le time-to-market et la satisfaction des utilisateurs.

Le Continuous Delivery en chiffres

Lors de ma dernière mission, j’ai intégré une équipe avec notamment l’objectif d’améliorer nos outils de build et de livraison. Cela nous a permis de passer d’une phase de compilation et de tests qui prenait un peu plus d’1h30 à un pipeline qui s’exécute en quinze minutes. Nous étions auparavant déjà dans un processus automatisé, mais relativement lent : le travail s’est surtout concentré sur l’optimisation de tests d’intégration, de leur exécution en parallèle et la mise à niveau du matériel. Là où nous avions cinq feedback par jour, il fallait potentiellement rechercher une erreur dans un groupe d’une vingtaine de commits. Aujourd’hui, nous sommes capables de rejouer l’intégralité des tests pour chaque commit, donc d’identifier précisément un commit responsable d’une régression.