Automatisation et rétroaction : boucler la boucle DevOps
4 min de lecture

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

Le chapitre 6, dernière partie de notre série DevOps pour la victoire, se penche sur le dernier pilier, mais ô combien essentiel, de notre transformation : l'automatisation et le retour d'information. Si le déploiement continu nous a aidés à publier plus rapidement, l'automatisation et le retour d'information nous ont permis d'apprendre plus rapidement, nous donnant les moyens de nous améliorer continuellement en toute confiance.

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

Dans toute transformation DevOps, la vitesse sans la sécurité mène tout droit à la catastrophe. À mesure que notre fréquence de déploiement augmentait, le besoin de contrôles automatisés et de retours d'information en temps réel est devenu critique, non seulement pour l'assurance de la 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 :

  • La détection précoce des problèmes avant qu'ils n'atteignent la production
  • La confiance dans les modifications, grâce à une validation répétable et fiable
  • Des indicateurs pertinents pour comprendre la santé du système et l'impact sur les utilisateurs

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

Après avoir amélioré la vélocité de développement, notre priorité suivante a consisté à identifier les goulets d'étranglement dans la boucle de rétroaction dès que l'équipe de développement marquait le travail comme « terminé ». Ici, la principale mesure du flux était la rapidité avec laquelle le travail achevé pouvait être déployé en production.

Le délai de mise en œuvre des modifications et la fréquence de déploiement sont des mesures clés pour évaluer l'efficacité avec laquelle le travail circule dans le système. Dans notre cas, le travail s'accumulait au stade de l'assurance qualité du système (SQA), créant un goulet d'étranglement pour la mise en production.

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

Dans la plupart des domaines, y compris le nôtre, la réglementation impose une série d'activités de validation pour garantir la qualité des logiciels. Cela comprend :

  • Les tests d'intégration
  • Les tests au niveau du système
  • Les tests non fonctionnels (par exemple, vérification du réseau, tests de performance)
  • Éléments de validation → Rapports de tests système, QI (qualification des installations), QO (qualification opérationnelle) et QP (qualification des performances).

Ces tâches doivent être exécutées dans des environnements contrôlés, distincts du développement, afin de garantir la conformité. Par conséquent, l'équipe QA du système travaille de manière autonome 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 délai nécessaire pour rendre le travail achevé prêt pour la production augmentait, avec une accumulation de tâches en attente du début des tests par le SQA. Conformément à notre approche fondamentale visant à améliorer le flux, il s'agissait d'un problème que nous devions résoudre avant que toute autre optimisation DevOps ne puisse démontrer une réelle valeur.

Principaux défis du flux du développement vers le SQA

L'amélioration du flux de travail du développement vers la QA du système présentait deux défis majeurs :

  1. Le retard dans le lancement 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 débuter et le temps nécessaire pour les achever. Dans ce modèle, le mieux que le SQA puisse faire est de préparer des scripts de test à l'avance et d'attendre que la définition de fini (DoD) de l'équipe de développement soit atteinte avant d'exécuter les tests.

Automatisation du SQA : un changement dans la stratégie de test

Le seul moyen d'améliorer ce flux est de miser massivement sur l'automatisation. Cependant, il ne s'agit pas seulement d'automatiser l'exécution des tests, cela exige un changement fondamental dans la façon d'aborder les tests. Cela comprend :

  • Redéfinir et réaligner les objectifs de la QA du système.
  • Réévaluer la manière dont la validation est effectuée pour répondre à la fois aux exigences de rapidité et de réglementation.
  • Repenser les outils et les cadres nécessaires pour prendre en charge efficacement l'automatisation.

L'un des changements clés de mentalité a consisté à passer de tests visant à confirmer que le logiciel développé fonctionne à des tests visant à guider le développement.

Cela signifiait créer, automatiser et exécuter des scripts de test dans un environnement où le code de développement est régulièrement intégré, avant même que la définition de fini (DoD) de la fonctionnalité ne soit atteinte. Ici, 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 pleinement opérationnelles.

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

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

Cette approche a permis au SQA de commencer la validation plus tôt, rendant les tests plus rapides et fournissant un retour d'information plus prompt à l'équipe de développement. Au lieu d'attendre qu'une fonctionnalité soit étiquetée comme terminée, les tests s'exécutent désormais 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 complété.

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

  • Abandon de l'automatisation de type UI-based → les tests d'API sont devenus la priorité.
  • Transition vers le développement piloté par le comportement (BDD) → Création de scripts de test en même temps que les user stories pour les 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 user stories soit toujours en cours, nous avons amélioré la collaboration entre le SQA et les équipes de développement, en les alignant dès le début du processus.

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

Pour y parvenir, nous avons appliqué l'approche d'équipe spécialisée issue de Team Topologies, en configurant l'équipe SQA comme une équipe facilitatrice. Au lieu d'être une fonction de test distincte en aval, les membres de l'équipe SQA ont été étroitement alignés sur le développement afin de garantir que la création de cas de test d'automatisation commence tôt et s'exécute 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 les tests au niveau du système avant de passer aux 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 au SQA, le rendant prêt pour le déploiement beaucoup plus rapidement.

Conclusion

Cette amélioration renforce un principe fondamental du DevOps : aborder la transformation en prenant en compte les compétences liées aux outils, à l'architecture et aux personnes, tout en se concentrant sur le flux. En automatisant la QA des systèmes, en intégrant les tests plus tôt dans le cycle et en alignant plus efficacement les équipes, nous avons considérablement réduit le goulet d'étranglement entre le développement et la validation du système, ce qui a accéléré les boucles de rétroaction et fluidifié les déploiements.

Conclusion de la série

Alors que nous terminons notre série DevOps pour la victoire, nous faisons le point sur le parcours qui nous a menés du chaos lié aux outils et aux processus manuels vers une organisation plus connectée, automatisée et autonome. De la définition de notre triangle DevOps au chapitre 1 à la mise en place d'un apprentissage fondé sur les retours au chapitre 6, chaque étape s'est appuyée sur la précédente pour impulser une transformation significative.

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

Cette transformation se poursuit, mais grâce aux bases que nous avons posées, nous sommes mieux armés que jamais pour apporter de la valeur plus rapidement, plus sûrement et plus intelligemment.

Merci de nous avoir suivis tout au long de ce parcours. Nous espérons que notre histoire inspirera votre propre évolution DevOps.

Restez curieux. Restez dans une démarche itérative. Et surtout, restez connectés.

S'abonner au blog de Freyr