La vélocité de livraison sans les incidents : ce que l'externalisation moderne du QA et du DevOps apporte

Le compromis qui ne devrait pas exister

La plupart des organisations d'ingénierie vivent la vélocité de livraison et la fiabilité comme des forces opposées. Livrez plus vite et vous livrez plus de bogues. Livrez avec précaution et vous livrez lentement. Les équipes finissent par livrer rarement, ce qui rend chaque livraison plus grosse et plus risquée, ce qui les pousse à livrer encore moins souvent. C'est un piège qui s'auto-entretient, et il contraint la feuille de route aussi sûrement que n'importe quel manque de ressources.

Ce piège n'est pas une loi de la nature. C'est le symptôme d'une infrastructure manquante : des tests non fiables et des livraisons manuelles, du tout ou rien. Corrigez l'infrastructure et le compromis se dissout. C'est ce que l'externalisation moderne du QA et du DevOps, bien menée, apporte réellement.

La confiance avant la couverture

L'instinct, quand l'automatisation des tests est faible, est d'ajouter davantage de tests. C'est généralement le mauvais premier geste. Une suite de tests à laquelle les ingénieurs ne font pas confiance, une suite qui échoue par intermittence pour des raisons sans rapport avec de vrais défauts, est pire qu'une suite plus petite mais fiable, car les ingénieurs apprennent à relancer les échecs plutôt qu'à les investiguer, et les véritables échecs sont écartés comme de l'instabilité.

Le bon premier geste est de rendre la suite existante digne de confiance. Faites baisser le taux d'instabilité jusqu'à ce qu'une compilation rouge signifie de façon fiable un vrai problème. Alors seulement, étendez la couverture, et étendez-la là où le risque réside réellement, guidé par l'historique des incidents en production et le taux de modification du code plutôt que par la poursuite d'un pourcentage de couverture. Une suite de confiance à couverture modérée vous protège mieux qu'une suite méfiée à couverture élevée.

Découpler les livraisons du risque

La seconde moitié de la réponse est la livraison progressive. Les indicateurs de fonctionnalité, les déploiements canari et le retour arrière automatisé séparent l'acte de déployer du code de l'acte de livrer une fonctionnalité aux utilisateurs. Un changement peut aller en production derrière un indicateur, être exposé à une petite tranche de trafic, être observé, et être annulé instantanément si quelque chose ne va pas, le tout sans un cycle de livraison complet.

C'est ce qui permet à la fréquence de livraison de s'élever sans que la gravité des incidents s'élève avec elle. Quand une livraison porte le risque de toute la plateforme, les équipes livrent rarement. Quand le risque est découplé et réversible, elles livrent constamment et en toute sécurité. Les organisations passent d'une poignée de livraisons par mois à une livraison hebdomadaire par équipe ou mieux, tandis que les défauts critiques échappés baissent au lieu d'augmenter.

Pourquoi le nearshore convient à ce travail

Le QA et le DevOps sont intensifs en collaboration. Ils vivent à l'intérieur des rituels de l'équipe d'ingénierie, de sa réponse aux incidents et de ses décisions d'architecture. C'est pourquoi le fuseau horaire compte tant pour ces fonctions en particulier. Une équipe nearshore en Colombie, sur la même journée de travail qu'une organisation d'ingénierie nord-américaine, participe plutôt que de transmettre. Et les meilleurs projets sont structurés de sorte que le client finisse par posséder la suite éprouvée et le pipeline de livraison, exploités par ses propres ingénieurs, plutôt que de les louer indéfiniment. Le compromis entre vitesse et fiabilité n'est réel que tant que l'infrastructure est manquante. Construisez-la, et vous pourrez livrer plus vite et casser moins en même temps.