Automatisation et retour d'information : Fermer la boucle DevOps
4 min de lecture

Dans le Chapitre 5 : Ramification et déploiement continu, nous avons exploré comment des branches à courte durée de vie et une plateforme de déploiement continu (CD) centralisée nous ont aidés à accélérer la livraison et à réduire les frictions d'intégration. Ces changements ont considérablement amélioré le flux de code vers la production – mais pour véritablement boucler la boucle de rétroaction DevOps, nous avions besoin de plus.

Chapitre 6, le dernier segment de notre série DevOps pour la victoire, aborde le dernier pilier, mais essentiel, de notre transformation : Automatisation et rétroaction. Si le déploiement continu nous a aidés à publier plus rapidement, alors l'automatisation et la rétroaction nous ont aidés à apprendre plus vite, nous permettant de nous améliorer continuellement avec confiance.

Pourquoi l'automatisation et le retour d'information sont importants

Dans toute transformation DevOps, la vitesse sans sécurité est une recette pour le désastre. À mesure que notre fréquence de déploiement augmentait, le besoin de vérifications automatisées et de retours en temps réel est devenu critique, non seulement pour l'assurance qualité, mais aussi pour l'autonomisation des équipes et la prise de décision.

Les systèmes d'automatisation et de retour d'information offrent aux équipes :

  • Détection précoce des problèmes avant qu'ils n'atteignent la production
  • Confiance dans les changements, grâce à une validation répétable et fiable.
  • Mesures pertinentes pour comprendre la santé du système et l'impact sur les utilisateurs

C'est la différence entre voler à l'aveugle et voler avec un tableau de bord.

Après avoir amélioré la vitesse de développement, notre prochaine priorité a été d'identifier les goulots d'étranglement dans la boucle de rétroaction une fois que l'équipe de développement avait marqué le travail comme « terminé ». Ici, la principale mesure du flux était la rapidité avec laquelle le travail terminé pouvait être déployé en production.

Le délai de mise en œuvre des changements et la fréquence de déploiement sont des indicateurs clés pour mesurer l'efficacité du flux de travail dans le système. Dans notre cas, le travail s'accumulait à l'étape de l'assurance qualité système (SQA), créant un goulot d'étranglement dans la préparation au déploiement.

Le goulot d'étranglement de l'assurance qualité du système

Dans la plupart des domaines, y compris le nôtre, les exigences réglementaires imposent une série d'activités de validation pour garantir la qualité des logiciels. Cela inclut :

  • Tests d'intégration
  • Tests système
  • Tests non fonctionnels (par exemple, vérification du réseau, tests de performance)
  • Artéfacts de validation → Rapports de tests système, QI (Qualification d'Installation), QO (Qualification Opérationnelle) et QP (Qualification de Performance)

Ces tâches doivent être effectuées dans des environnements contrôlés, distincts du développement, afin d'assurer la conformité. C'est pourquoi l'équipe QA du système opère de manière indépendante, et les tests ne peuvent commencer qu'une fois le travail de l'équipe de développement terminé.

Nos tableaux de bord ont montré que le temps nécessaire pour faire passer le travail terminé au statut de prêt pour la production augmentait, avec plus de travail en attente que la SQA ne commence les tests. Suivant notre approche fondamentale pour améliorer le flux, c'était un problème que nous devions résoudre avant que toute autre optimisation DevOps ne puisse montrer une réelle valeur.

Principaux défis dans le flux de Dev vers SQA

Il y avait deux défis majeurs pour améliorer le flux de travail du développement à l'assurance qualité système :

  1. Le délai de démarrage des tâches SQA
  2. La vitesse à laquelle la validation du système pouvait être exécutée

Si les tests SQA sont principalement manuels, ils ne peuvent commencer qu'une fois le code entièrement développé et déployé dans des environnements contrôlés. Cela détermine à la fois le moment où les tests peuvent commencer et le temps qu'il faudra pour les achever. Le mieux que le SQA puisse faire dans ce modèle est de préparer les scripts de test à l'avance, en attendant que la « Definition of Done (DoD) » de l'équipe de développement soit atteinte avant d'exécuter les tests.

Automatiser la SQA : Un changement de stratégie de test

La seule façon d'améliorer ce flux est de se concentrer massivement sur l'automatisation. Cependant, il ne s'agit pas seulement d'automatiser l'exécution des tests, cela nécessite un changement fondamental dans la manière d'aborder les tests. Cela inclut :

  • Redéfinir et réaligner les objectifs de l'assurance qualité du système.
  • Réévaluer la manière dont la validation est effectuée pour répondre à la fois aux exigences de rapidité et aux exigences réglementaires.
  • Réimaginer les outils et les cadres nécessaires pour soutenir efficacement l'automatisation.

L'un des changements majeurs de mentalité a été de passer des tests visant à confirmer le bon fonctionnement du logiciel développé → à des tests visant à guider le développement.

Cela impliquait la création, l'automatisation et l'exécution de scripts de test dans un environnement où le code de développement est régulièrement déployé, avant même que la définition de « Done » (DoD) de la fonctionnalité ne soit atteinte. Dans ce contexte, les échecs de test n'indiquent pas un défaut, mais fournissent plutôt un aperçu précoce des parties de la fonctionnalité qui ne sont pas encore implémentées ou entièrement fonctionnelles.

Avec des pipelines de livraison continue et une stratégie de branching affinée en place, où les branches de fonctionnalités sont fusionnées fréquemment dans la branche principale et déployées sur le cloud, nous avons mis en place un environnement dédié où ces tests système automatisés pouvaient s'exécuter en continu.

Retour d'information plus rapide grâce aux tests automatisés

Cette approche a permis à l'équipe QA du système de commencer la validation plus tôt, accélérant ainsi les tests et fournissant un retour d'information plus rapide à l'équipe de développement. Au lieu d'attendre qu'une fonctionnalité soit marquée comme terminée, les tests sont désormais effectués en parallèle avec le développement, offrant aux équipes des informations en temps réel sur ce qui fonctionne et ce qui doit encore être achevé.

Parallèlement, l'automatisation des cas de test a nécessité de repenser les stratégies de test.

  • S'éloigner de l'automatisation basée sur l'interface utilisateur → les tests d'API sont devenus la priorité.
  • Passage au développement piloté par le comportement (BDD) → Création de scripts de test parallèlement aux récits utilisateurs à inclure dans les critères d'acceptation.

Bien que l'adoption complète du BDD dès le début de la création des récits utilisateurs soit encore en cours, nous avons amélioré la collaboration entre les équipes SQA et de développement, en les alignant dès le début du processus.

Aligner l'SQA avec le développement : L'influence des topologies d'équipe

Pour y parvenir, nous avons appliqué l'approche par équipe spécialisée issue de Team Topologies, en configurant l'équipe SQA comme une équipe habilitante. Au lieu d'être une fonction de test distincte et en aval, les membres de l'équipe SQA ont été étroitement alignés avec le développement pour s'assurer que la création de cas de test automatisés commence tôt et se déroule en continu à mesure que le code est développé.

Une condition préalable essentielle à cette approche est de disposer d'un environnement de test Cloud-based pour exécuter des tests au niveau du système avant de passer à des environnements contrôlés. Bien que cela entraîne des coûts d'infrastructure supplémentaires, cela augmente considérablement le flux de travail du développement à la SQA, le rendant prêt au déploiement beaucoup plus rapidement.

Conclusion

Cette amélioration renforce un principe fondamental de DevOps : aborder la transformation en considérant les compétences en matière d'outils, d'architecture et de personnes tout en se concentrant sur le flux. En automatisant l'assurance qualité (QA) du système, en intégrant les tests plus tôt dans le cycle et en alignant les équipes plus efficacement, nous avons considérablement réduit le goulot d'étranglement entre le développement et la validation du système, accélérant les boucles de rétroaction et rendant les déploiements plus fluides.

Conclusion de la série

Alors que nous clôturons notre série DevOps pour la Victoire, nous réfléchissons au parcours allant du chaos des outils et des processus manuels à une organisation plus connectée, automatisée et autonome. De la définition de notre Triangle DevOps au Chapitre 1 à l'établissement de l'apprentissage basé sur le feedback au Chapitre 6, chaque chapitre s'est appuyé sur le précédent pour favoriser une transformation significative.

Voici un récapitulatif rapide de notre série :

Cette transformation est en cours, mais avec les bases que nous avons construites, nous sommes mieux équipés que jamais pour offrir de la valeur plus rapidement, plus sûrement et plus intelligemment.

Merci de nous avoir accompagnés dans ce parcours. Nous espérons que notre histoire inspirera votre propre évolution DevOps.

Restez curieux. Restez itératif. Et surtout, restez connecté.

S'abonner au blog Freyr