Formation DevOps écrite

Pourquoi instaurer un processus de revue continue pour garantir la qualité ?

Vos organisations s’appuient fortement sur les revues, audits, inspections et approbations juste avant les déploiements en production. Ces inspections sont généralement réalisées par des personnes qui participent de loin à votre travail, quand elles y participent. Pire, les personnes chargées d’inspecter et d’approuver comprennent parfois mal ce travail. Vous devez alors le leur expliquer au moment de mettre votre code en production.

Les problèmes posés par les mécanismes de contrôle externes

Dans la plupart des organisations, il est plus facile de mettre en place des mécanismes de contrôle que de bâtir une confiance mutuelle. Ajouter des questions aux formulaires de changement, multiplier les niveaux d’approbation et allonger les délais d’examen des changements sont des problèmes typiques des contrôles externes.

Dans une culture de commandement et de contrôle où règne la méfiance, les incidents se répètent. Un cercle vicieux s’installe : le travail effectué et les problèmes récurrents manquent de visibilité, et les équipes travaillent par gros lots pour réduire autant que possible le nombre de déploiements pénibles. Des délais de livraison plus longs nuisent à la rapidité de mise sur le marché. Des retours lents, tardifs et difficiles à exploiter empêchent vos équipes d’apprendre de leurs erreurs.

Une organisation DevOps compétente comme la vôtre sait que les personnes les plus proches du travail et des problèmes associés sont celles qui les connaissent le mieux. Des contrôles et approbations externes supplémentaires n’apportent donc aucune valeur à votre flux. D’où l’un des plus grands défis actuels de la direction : instaurer une culture de confiance dans laquelle le travail est transparent et où le respect sincère et la confiance mutuelle font partie du quotidien.

Remplacez la dépendance aux inspections périodiques par des revues par les pairs au quotidien. Faites collaborer en continu les développeurs, les ingénieurs d’exploitation et les spécialistes de l’assurance qualité et de la sécurité de l’information au sein de l’équipe DevOps. Ils examineront mutuellement leur travail pour sécuriser les déploiements.

Coordonner un travail complexe sans mécanismes de contrôle externes

Un projet est déjà complexe pour une seule équipe et le devient davantage lorsque plusieurs équipes travaillent sur différents composants du même système. Voici quelques mesures pour aider votre équipe DevOps et vous-même à garder la maîtrise :

• Des comités de changement composés de spécialistes du domaine, au-delà des seuls responsables, peuvent vous aider à repérer les dépendances entre les équipes avant les changements.
• Les architectures à couplage faible fondées sur l’architecture orientée services (SOA) et les microservices réduisent les dépendances et les efforts de communication.
• Les représentants techniques des équipes DevOps devraient identifier les dépendances et l’ordre de développement et de déploiement.
• Échanger en continu sur des plateformes de discussion communes pour synchroniser les changements, comprendre la manière dont les autres les interprètent et vérifier cette compréhension.
• Les changements plus importants et risqués, comme les migrations ou les modifications d’infrastructure, exigent des répétitions dans des environnements de test et des mesures techniques comme le basculement et le retour en arrière complet.

Les organisations DevOps les plus performantes privilégient les revues par les pairs et recourent moins aux approbations externes

De nombreuses organisations DevOps de premier plan, dont Amazon, Netflix, Etsy et GitHub, utilisent un processus de revue et de déploiement par «pull request». Voici son fonctionnement :

1. La développeuse crée une branche de développement distincte à partir du tronc. Cette branche ne devrait pas durer plus de quelques jours ouvrés et devrait porter un nom clair et descriptif, comme « login-screen-v2 ». La développeuse travaille localement sur son poste et intègre régulièrement ses modifications dans le système de gestion des versions.
2. Quand la développeuse estime que la branche est prête à être fusionnée avec le tronc, elle ouvre une « pull request » pour demander des retours.
3. Après avoir reçu les retours et l’approbation des autres membres de son équipe DevOps, la développeuse fusionne son code avec le tronc, puis le déploie en production.

Pour des changements importants, comme des modifications de schémas de bases de données ou des changements susceptibles d’affecter la sécurité de l’information, elle peut également envoyer des « pull requests » supplémentaires pour solliciter l’avis d’autres spécialistes de l’organisation, comme des administrateurs de bases de données ou des spécialistes de la sécurité de l’information.

Appliquez aussi le principe des petits lots aux revues de code. Sinon, les revues durent plus longtemps et font peser une charge importante sur les ingénieurs chargés de les effectuer. Plus un changement est important, plus son risque augmente de façon exponentielle et moins la revue est fiable. Si un changement est trop gros et difficile à comprendre, demandez à la développeuse de le diviser en plusieurs parties plus petites et compréhensibles.

Chaque membre de l’équipe DevOps, quels que soient son ancienneté et son niveau d’expérience, doit faire relire ses modifications par quelqu’un. Chacun devrait suivre les modifications intégrées pour repérer et régler les conflits avant qu’ils causent des problèmes plus graves dans le pipeline ou, pire, lors d’un déploiement en production.

La programmation en binôme, seule ou associée au développement piloté par les tests (TDD), où une personne écrit le code de l’application et l’autre les tests automatisés, permet des revues par les pairs pendant l’écriture du code. À taille d’équipe et exigences de projet identiques, les mesures ont montré que la programmation en binôme prend 15 % de temps supplémentaire mais réduit les erreurs de codage de 85 %. C’est une pratique importante que votre équipe DevOps et vous-même devriez envisager.

Vous pouvez aussi envisager les revues de code au poste de travail, les notifications automatisées des modifications intégrées et les outils d’aide à la revue et à l’amélioration de la qualité du code.

CONCLUSION

Rendez chaque équipe DevOps responsable de la qualité de ses livrables. Créez une culture qui valorise autant la revue régulière et rigoureuse du code que l’écriture de code de qualité.