Le principal intérêt du déploiement continu (CD) est d'abaisser le risque des livraisons. Les pratiques d'automatisation exhaustive des tests et d'intégration continue ont le plus d'impact sur la performance du SI. Les recherches sur ces sujets montrent que l'implémentation des pratiques du CD amènent une meilleure performance SI et les meilleurs atteignent à la fois un rythme et une stabilité accrus, comme l'explique Jez Humble.
InfoQ a échangé avec Jez Humble sur les recherches en cours concernant la relation entre le CD, la perfomance des SI et les bénéfices à tirer pour les organisations du CD, l'impact des pratiques du CD sur la performance, et des conseils pour les organisations qui voudraient déployer le CD.
InfoQ : Pourquoi un travail de recherche entre le CD et la performance SI ?
Jez Humble : Depuis la sortie du livre sur le CD en 2010, l'idée est passée de controverse à mainstream, même dans les grandes entreprises de services financiers et les gouvernements. Cependant, je voulais comprendre quels aspects étaient importants et pourquoi, et essayer de construire un modèle quantitatif pour en explorer les bénéfices. Le travail que j'ai accompli avec le DevOps Research and Assessment avec mon associé le Dr Nicole Forsgren et Gene Kim, en même temps qu'avec la super équipe de Puppet, ont dépassé mes attentes et de loin.
Nous avons trouvé une méthode statistiquement significative pour modéliser la performance IT, montrant que l'implémentation des pratiques du CD mènent à de meilleures performances, et montrant que les meilleurs atteignent à la fois un rythme plus important - mesuré en termes de fréquence de livraisons et de temps de cycle - et un plus haut niveau de stabilité.
InfoQ : Quels bénéfices les organisations obtiennent-elles en appliquant du déploiement continu ?
Humble : Comme je le décrivais sur mon site sur le CD, le principal bénéfice, et le premier levier derrière le CD, est de baisser le risque de livraison. Quand avec Dave Farley, nous avons écrit le livre, notre objectif premier était de permettre aux individus de livrer de nouvelles versions de logiciels d'entreprise complexes durant des heures de bureau plutôt que d'opérer des livraisons complexes, orchestrées et souvent manuelles impliquant une coupure de services les soirs et week-ends.
Néanmoins, ces mêmes techniques facilitent aussi une meilleure qualité logiciel, une accélération du time-to-market, des livraisons plus fréquentes, et réduisent le coût du run. En réduisant substantiellement le coût de transaction du déploiement de changements, nous avons renversé l'économie du processus de livraison logiciel pour rendre viable la livraison par petits morceaux (small batch - NdT). Dès lors les principes et pratiques du CD sont aussi des prérequis pour d'autres techniques promues par le mouvement Lean StartUp comme l'A/B testing, la livraison rapide et l'évolution rapide des MVP grâce aux retours utilisateurs.
Encore plus intéressant, notre recherche montre que le CD réduit le burnout, rendant les équipes plus contentes, et améliore la culture de l'organisation. Cela ne signifie pas que c'est la panacée - le CD implique un investissement conséquent et vaut pour des produits et services dont il est probable qu'ils évoluent significativement durant leur vie.
InfoQ : Quelles pratiques de CD ont le plus d'impact sur la performance IT ?
Humble : L'automatisation des tests et l'intégration continue sont les plus importantes, la gestion des versions à la fois du code et des infrastructures venant juste après. Le CD a également un impact significatif sur la performance IT, expliquant quasiment 1/3 de la variance.
Cependant, ces pratiques techniques impliquent un investissement, et même aujourd'hui, plus de 15 ans après l'explication de son importance dans eXtreme Programming, beaucoup d'équipes ne les ont pas encore adoptées. Beaucoup d'organisations n'ont toujours pas de tests automatisés fiables, exhaustifs et maintenables pour leurs services critiques. Beaucoup d'équipes disant pratiquer le CD ne le font pas. J'ai un test pour vérifier si les personnes pratiquent vraiment l'intégration continue : les développeurs poussent-ils vers un trunk/master partagé au moins tous les jours ? Chaque commit induit-il le démarrage automatisé des builds et tests ? Et quand le build échoue, est-il en moyenne corrigé en moins de dix minutes ? Peu de personnes peuvent répondre "oui" aux trois questions. L'intégration continue et les tests automatisés sont difficiles et impliquent un investissement important, mais les chiffres montrent un énorme impact sur la performance de livraison.
InfoQ : Y a-t-il aussi des pratiques semblant avoir un impact moindre ou faible ? Savez-vous pourquoi ?
Humble : Nous avons découvert qu'une approbation par des personnes externes à l'équipe de développement réduit considérablement la cadence, avec un impact sur la stabilité assez faible. Des processus d'approbations internes comme le pair programming et la revue de code sont bien plus efficaces. Notre hypothèse est qu'il est juste très dur de comprendre l'impact d'un changement de code par inspection. Il est plus intéressant en termes de gestion de risque de s'appuyer sur les tests automatisés augmentés d'un processus léger d'approbation interne.
Un autre élément surprenant pour certains est qu'il n'y a pas de corrélations entre la création a priori et le maintien des tests d'acceptation par la QA et la performance IT. Il est préférable que les développeurs le fassent, ou de les faire travailler conjointement avec les testeurs. Notre hypothèse est ici que l'implication des développeurs dans la création et le maintien des tests automatisés exercent une force sur le logiciel qui le rend plus testable, ce qui à son tour rend les tests plus fiables. Mon expérience personnelle est qu'en cas d'absence d'implication des développeurs dans l'automatisation des tests, ces derniers deviennent très coûteux à maintenir, et qu'ils échouent souvent car les développeurs ne s'y intéressent pas.
InfoQ : Quels sont vos conseils pour les organisations voulant déployer du CD ?
Humble : le CD est un voyage, pas une destination, et revient à l'amélioration continue. Commencez par définir et communiquer sur des objectifs métier mesurables que vous voulez atteindre, puis assurez-vous que les équipes ont le temps et les moyens de réussir. Améliorer les livraisons implique typiquement un investissement conséquent en automatisation de tests et de déploiement de concert avec une architecture permettant un build facilement testable des logiciels sur le poste de travail du développeur et un déploiement simplifié sans, par exemple, trop d'orchestration. Il vous faut être prêt à cela. Il a fallu quatre ans à Amazon pour passer d'une architecture monolithique à une architecture orientée service pouvant être déployée en continu.
Cependant, une des choses passionnantes à propos du CD est que vous pouvez souvent faire de grands changements locaux sans des tonnes de travail. Mon expérience originelle avec le CD en 2005 était l'inclusion dans une petite équipe travaillant sur l'automatisation du déploiement d'une grosse application où nous sommes passés d'un processus de déploiement en plusieurs jours vers un déploiement en moins d'une heure, avec une inaccessibilité inférieure à la seconde et un retour arrière complétement automatisé en moins d'une seconde en utilisant le pattern de déploiement bleu/vert. Nous y sommes parvenus en quelques mois, et uniquement avec bash et CVS. Ceci m'amène au point suivant : les gens tendent à se focaliser sur l'outillage. Eviter les mauvais outils est vraiment important, mais il y a tant d'outils super (et gratuits !) que vous ne devriez pas perdre de temps à discuter des meilleurs à utiliser. Concentrez-vous plutôt sur l'architecture et la culture.