Automatisation et retour d'expérience : Fermer la boucle DevOps
4 min lire

En Chapitre 5 : Branchements et déploiement continunous avons exploré comment des branches de courte durée et une plateforme centralisée de déploiement continu us ont permis d'accélérer la livraison et de 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 vraiment compléter la boucle de rétroaction DevOps, nous avions besoin de plus.

Le chapitre 6, dernier segment de notre série DevOps for the Win, se penche sur le dernier pilier vital de notre transformation : L 'automatisation et le retour d'expérience. Si le déploiement continu us a aidés à publier plus rapidement, l'automatisation et le retour d'expérience us ont permis d'apprendre plus vite, ce qui us a permis de nous améliorer continuellement en toute confiance.

L'importance de l'automatisation et du retour d'information

Dans toute transformation DevOps, la vitesse sans la sécurité est une recette pour le désastre. À mesure que la fréquence de nos déploiements augmentait, le besoin de contrôles automatisés et de retours d'information en temps réel devenait critique, non seulement pour l'assurance qualité, mais aussi pour l'autonomisation de l'équipe et la prise de décision.

L'automatisation et les systèmes de retour d'information permettent aux équipes :

  • Détection précoce des problèmes avant qu'ils n'reach production
  • Confiance dans les changements, grâce à une validation reproductible et fiable
  • Des mesures perspicaces pour comprendre la santé du système et l'impact sur l'utilisateur

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, nous nous sommes ensuite attachés à identifier les goulets d'étranglement dans la boucle de retour d'information, une fois que l'équipe de développement a marqué le travail comme "terminé". Dans ce cas, la principale mesure du flux était la rapidité avec laquelle le travail achevé pouvait être déployé en production.

Le délai de changement et la fréquence de déploiement sont des paramètres clés pour mesurer l'efficacité avec laquelle le travail progresse dans le système. Dans notre cas, le travail s'accumulait au stade de l'QA système (AQS), ce qui créait un goulot d'étranglement dans la préparation du déploiement.

Le goulot d'étranglement de l'QA 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. Il s'agit notamment de

  • Tests d'intégration
  • Tests au niveau du système
  • Tests non fonctionnels (par exemple, vérification du réseau, tests de performance)
  • Artéfacts de validation → Rapports d'essais du système, QI (qualification de l'installation), QO (qualification opérationnelle) et QP (qualification des performances)

Ces tâches doivent être effectuées dans des environnements contrôlés, séparés du développement, afin de garantir la conformité. Pour cette raison, l'équipe d'QA système travaille de manière indépendante et les tests ne peuvent commencer qu'une fois que l'équipe de développement a terminé son travail.

Nos tableaux de bord montraient que le temps nécessaire pour que le travail achevé soit prêt pour la production augmentait, avec davantage de travail en attente de l'AQS pour commencer les tests. Conformément à notre approche fondamentale de l'amélioration des flux, il s'agissait d'un problème que nous devions résoudre avant que d'autres optimisations DevOps puissent apporter une réelle valeur ajoutée.

Principaux défis dans le flux entre le développement et l'assurance qualité

L'amélioration du flux de travail entre le développement et l'QA système s'est heurtée à deux difficultés majeures :

  1. Le retard dans le démarrage des tâches de l'AQS
  2. La vitesse à laquelle la validation du système pourrait être exécutée

Si les tests AQS sont essentiellement 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 mener à bien. Le mieux que l'AQS puisse faire dans ce modèle est de préparer des scripts de test à l'avance, en attendant que l'équipe de développement atteigne la définition de l'achèvement (DoD) avant d'exécuter les tests.

Automatiser l'AQS : Un changement dans la 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éorienter les objectifs de l'QA systèmes.
  • Réévaluer la manière dont la validation est effectuée pour répondre aux exigences de rapidité et de réglementation.
  • Réimaginer les outils et les cadres nécessaires pour soutenir efficacement l'automatisation.

L'un des principaux changements d'état d'esprit a consisté à passer de tests visant à confirmer que le logiciel développé fonctionne → à des tests visant à guider le développement.

Cela signifie que des scripts de test ont été créés, automatisés et exécutés dans un environnement où le code de développement est régulièrement mis en place, avant même que la date de fin de la fonctionnalité ne soit atteinte. Dans ce cas, les échecs des tests 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 mises en œuvre ou pleinement fonctionnelles.

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

Un retour d'information plus rapide grâce à l'automatisation des tests

Cette approche a permis à l'QA système de commencer la validation plus tôt, ce qui a accéléré les tests et fourni un retour d'information plus rapide à l'équipe de développement. Au lieu d'attendre qu'une fonctionnalité soit considérée comme terminée, les tests se déroulent désormais parallèlement au développement, ce qui permet aux équipes de savoir en temps réel ce qui fonctionne et ce qu'il reste à faire.

Dans le même temps, 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 d'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 de l'histoire de l'utilisateur soit encore un travail en cours, nous avons amélioré la collaboration entre l'AQS et les équipes de développement, en les alignant dès le début du processus.

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

Pour y parvenir, nous avons appliqué l'approche d'équipe spécialisée de Team Topologies, en mettant en place l'équipe SQA en tant qu'équipe habilitante. Au lieu d'être une fonction de test séparée, en aval, les membres de l'équipe SQA ont été étroitement alignés sur le développement pour s'assurer que la création de cas de test d'automatisation commence tôt et se poursuive en continu au fur et à 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 effectuer 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 entre le développement et l'assurance qualité, ce qui permet un déploiement beaucoup plus rapide.

Conclusion

Cette amélioration renforce un principe fondamental de DevOps - aborder la transformation en tenant compte des compétences en matière d'outils, d'architecture et de personnel tout en se concentrant sur le flux. En automatisant l'QA 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 retour d'information et rendant les déploiements plus fluides.

Conclusion de la série

Alors que nous clôturons notre série DevOps for the Win, nous nous penchons sur le chemin parcouru pour passer du chaos de l'outillage et des processus manuels à une organisation plus connectée, automatisée et responsabilisée. De la définition de notre triangle DevOps au chapitre 1 à la mise en place d'un apprentissage basé sur le retour d'expérience au chapitre 6, chaque chapitre s'est appuyé sur le précédent pour conduire à une transformation significative.

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

Cette transformation est en cours, mais avec les fondations que nous avons construites, nous sommes mieux équipés que jamais pour apporter de la valeur plus rapidement, de manière plus sûre et plus intelligente.

Nous vous remercions de nous avoir suivis tout au long de ce voyage. Nous espérons que notre histoire vous inspirera dans votre propre évolution DevOps.

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

S'abonner au blog de Freyr