Google PCD: Tests, ingénierie de la qualité et gestion des mises en production sécurisées — Guide d'étude

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Fait partie du Google Professional Cloud Developer — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Google, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Les équipes à haute vélocité sur Google Cloud associent des tests rigoureux à une livraison progressive pour réduire les risques tout en accélérant le changement. Une stratégie robuste couvre les tests unitaires jusqu’aux tests de bout en bout, la simulation réaliste des données et des dépendances, des portails de qualité automatisés et des modèles de publication contrôlés tels que le canary et le blue-green. L’observabilité, la responsabilité (ownership) et une vérification post-publication disciplinée bouclent la boucle. Cette section détaille comment concevoir pour la fiabilité, isoler les risques et promouvoir en toute sécurité les builds à travers les environnements avec les services Google Cloud.

Stratégie de test et gestion des données

Pyramide des tests et types de tests

Tests unitaires : Vérification rapide et isolée des fonctions, classes et petits modules. Ils devraient constituer la majorité de la suite de tests. Exécutez-les à chaque commit et pull request.
Tests d’intégration : Valident les interactions entre les composants, comme l’application et sa banque de données ou sa file d’attente. Utilisez les émulateurs Google Cloud lorsqu’ils sont disponibles.
Tests de contrat : Les contrats pilotés par le consommateur (consumer-driven contracts) pour les microservices empêchent les changements cassants d’API. Validez le comportement du fournisseur par rapport au schéma et à la sémantique attendus par le consommateur avant l’intégration. Utilisez Pact ou des outils similaires ; versionnez votre API et publiez les schémas.
Tests de bout en bout : Exercent le chemin complet du système en utilisant une configuration, une identité et des politiques réseau similaires à la production. Limitez leur nombre, parallélisez-les et exécutez-les sur des environnements de pré-production.
Tests de fumée (smoke tests) : Sondes minimales confirmant que les dépendances critiques, les routes et les bilans de santé (health checks) se comportent correctement après chaque déploiement. Ce sont vos premières vérifications post-déploiement.

Gestion des données de test, isolation, reproductibilité et parité des environnements

Alimentation des données (data seeding) : Générez de petits jeux de données déterministes pour les tests unitaires et des jeux de données plus grands et représentatifs pour les tests d’intégration/performance. Alimentez les données à partir de fixtures enregistrées dans le contrôle de code source.
Isolation : Assurez-vous que les tests ne partagent pas d’état. Utilisez des bases de données éphémères, des espaces de noms GKE isolés et des préfixes uniques pour les objets Cloud Storage. Pour SQL, créez des schémas par test ; pour Pub/Sub, générez des sujets/abonnements temporaires.
Reproductibilité : Épinglez les versions des dépendances, rendez les builds hermétiques et fixez les graines aléatoires (random seeds). Stockez les conteneurs de test avec leurs digests dans Artifact Registry.
Parité des environnements : Standardisez les images de conteneurs et l’infrastructure-as-code entre les environnements de développement, d’assurance qualité (QA), de pré-production (staging) et de production. Gardez la configuration hors des images et utilisez des métadonnées et des secrets spécifiques à l’environnement. Pour Compute Engine, stockez les valeurs par déploiement dans les métadonnées du modèle d’instance ; pour la parité entre projets, configurez une clé de métadonnées d’environnement et lisez-la au démarrage pour sélectionner la configuration spécifique à l’environnement.

Mocking, émulateurs, fakes et services sandbox

Mocks/stubs : Remplacez les collaborateurs au niveau unitaire pour isoler la logique et supprimer les appels réseau. Évitez le sur-mocking (over-mocking) ; affirmez le comportement, pas les détails d’implémentation.
Émulateurs : Préférez les émulateurs officiels pour les tests d’intégration. Exemples : émulateurs Firestore/Datastore, Pub/Sub, Spanner et Bigtable. Ils offrent une fidélité d’API sans frais cloud et accélèrent la CI.
Fakes : Lorsqu’aucun émulateur n’existe, exécutez des fakes locaux légers (par exemple, un faux service de stockage d’objets) ou des services sandbox partagés avec une isolation et des quotas stricts.
Simulation de dépendances externes : Pour les API tierces, exécutez des fakes basés sur des contrats derrière un maillage de services (service mesh) ou une passerelle API ; configurez les délais d’attente (timeouts), les nouvelles tentatives (retries) et l’injection de chaos pour tester la gestion des pannes.

Modes de défaillance courants et compromis

Une dépendance excessive aux tests de bout en bout ralentit l’itération ; investissez dans les tests unitaires et de contrat pour détecter les problèmes plus tôt.
Les environnements de test partagés et à longue durée de vie accumulent de la dérive et de la pollution de données. Préférez les environnements éphémères et une configuration/démontage idempotente.
Les émulateurs peuvent ne pas refléter parfaitement la production. Utilisez des tests E2E en pré-production (staged) avec de vrais services avant la promotion.

Exemple court de Cloud Build pour séparer les étapes en échec

steps:
- name: gcr.io/cloud-builders/gcloud
  entrypoint: bash
  args: ['-c', 'make compile && make unit']
- name: gcr.io/cloud-builders/gcloud
  entrypoint: bash
  args: ['-c', 'docker build -t $IMAGE .']
- name: gcr.io/cloud-builders/gcloud
  entrypoint: bash
  args: ['-c', 'make integration']  # run against emulators or ephemeral env
images: ['$IMAGE']

Des étapes séparées garantissent que l’historique du build identifie précisément si la compilation/les tests unitaires, la construction (build) ou l’intégration a échoué.

Tests non fonctionnels et qualité du code

Tests de performance

Types : Tests de charge (état stable), de stress (au-delà du pic), d’endurance (longue durée) et de capacité.
Outillage : Utilisez Cloud Monitoring pour les SLO et les alertes, Cloud Trace pour l’analyse détaillée de la latence, et Cloud Profiler pour identifier les points chauds (hot paths). Pour GKE, mettez à l’échelle avec Cluster Autoscaler et HPA ; pour les workers Pub/Sub, le HPA sur des métriques externes gère la mise à l’échelle due aux pics de charge.
Tests en production : Utilisez les lancements obscurs (dark launches) et la duplication de requêtes (request mirroring) pour évaluer en toute sécurité de nouveaux backends avec le trafic de production. External HTTP(S) Load Balancing prend en charge la duplication de requêtes ; Anthos Service Mesh prend en charge le traffic shadowing.

Tests de sécurité

SAST/analyse de secrets : Exécutez des analyseurs statiques en CI et rejetez les informations d’identification codées en dur. Stockez les secrets dans Secret Manager avec un accès basé sur le principe de moindre privilège.
Analyse des dépendances et des images : Activez Container Analysis sur Artifact Registry. Appliquez des politiques avec Binary Authorization, en exigeant des attestations qu’aucune vulnérabilité critique n’existe avant le déploiement.
DAST : Analysez les environnements de pré-production (staging) avec des scanners authentifiés et bloquez les mises en production en cas de découvertes critiques.

Accessibilité et régression

Accessibilité : Intégrez des vérifications d’accessibilité (a11y) automatisées (par exemple, Lighthouse CI) dans les vérifications non bloquantes avant fusion (pre-merge) ; corrigez avant la mise en production.
Suites de régression : Maintenez des suites de régression organisées et stables pour les parcours critiques. Exécutez des tests de fumée (smoke tests) à chaque déploiement et une régression complète sur les candidats à la mise en production (release candidates).

Analyse statique, portails de qualité et revue de code

Analyse statique : Configurez des linters et des formateurs adaptés au langage en tant que vérifications avant soumission (pre-submit). Utilisez Bazel ou un outil similaire pour paralléliser.
Portails de qualité : Faites échouer les builds en cas de dépassement de seuils (couverture, complexité, erreurs de lint). Publiez les résultats dans les journaux Cloud Build.
Revue de code : Exigez une revue par deux personnes pour les changements risqués, des CODEOWNERS pour les chemins critiques, et une CI avant soumission (presubmit) sur les tags utilisés pour les mises en production.
Chaîne d’approvisionnement (Supply chain) : Générez des SBOM, signez les artefacts et stockez la provenance. Appliquez les vérifications d’attestation dans Binary Authorization.

Livraison progressive et publications sécurisées

Stratégies de déploiement

Rolling : Remplacer les pods ou les instances de manière incrémentielle. Faible risque pour les services sans état (stateless) ; à combiner avec des readiness probes et des paramètres de surge/disponibilité.
Blue-green : Mettre en place un nouvel environnement complet, effectuer la vérification, puis basculer le trafic. Permet un rollback instantané en restaurant la configuration du load balancer. Idéal lorsque vous avez besoin d’une solution de repli immédiate.
Canary : Dévier progressivement un faible pourcentage du trafic vers la nouvelle version tout en surveillant les métriques clés. Promouvoir automatiquement si la version est saine ; effectuer un rollback en cas de régressions.
Répartition du trafic (Traffic splitting) : Router par pourcentage ou par attributs (en-têtes, cookies, user-agent) avec GKE plus Anthos Service Mesh, ou utiliser la répartition intégrée dans Cloud Run et App Engine.

Feature flags et expérimentation

Feature flags : Découpler le déploiement de la publication (release). Utiliser des indicateurs pour un déploiement progressif (gradual rollout), des interrupteurs d’urgence (kill switches) et des bascules d’expérimentation. Stocker de manière centralisée (par exemple, un service de feature flags managé ou un magasin de configuration protégé par IAM). Garder des durées de vie courtes pour les indicateurs et supprimer le code obsolète.
Lancements à l’aveugle (Dark launches) : Déployer des fonctionnalités désactivées ; valider via des utilisateurs internes ou du trafic synthétique.
Trafic fantôme (Shadow traffic) : Répliquer les requêtes de production vers de nouveaux services sans impacter les utilisateurs ; comparer les réponses pour détecter les régressions.
Expérimentations contrôlées : Mettre en œuvre un routage A/B ou multivarié avec des règles de service mesh. Pour les expérimentations basées sur le user-agent, router par correspondance d’en-tête (header match).

Portes de déploiement, approbations, rollback et observabilité

Portes de déploiement (Deployment gates) : Ajouter des tests d’intégration avant le déploiement (predeploy) et des vérifications de base/santé après le déploiement (postdeploy smoke/health checks). Pour la promotion d’environnement, utiliser des déclencheurs basés sur des tags pour séparer la construction (build) de la publication (release).
Approbations manuelles : Exiger une approbation humaine à des étapes clés, comme le passage du staging à la production. Cloud Deploy prend en charge les étapes d’approbation manuelle pour chaque cible (target).
Rollback automatique : Définir des SLO et des politiques d’alerte ; lorsqu’un canary dépasse les seuils de taux d’erreur ou de latence, effectuer un rollback automatique en invoquant l’API de déploiement. Maintenir des rollbacks rapides et bien rodés.
Observabilité des publications : Instrumenter les publications avec des libellés de version dans les métriques et les journaux (logs). Exporter les métriques Prometheus vers Cloud Monitoring et créer des métriques basées sur les journaux pour les modèles d’erreur afin de corréler la télémétrie de manière rentable.

Exemple court de routage ASM pour un canary basé sur l’en-tête

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
spec:
  http:
  - match:
    - headers:
        user-agent:
          regex: ".*Android.*"
    route:
    - destination: { host: svc, subset: v2 }  # canary
  - route:
    - destination: { host: svc, subset: v1 }  # stable

Fiabilité des tests, boucles de rétroaction et discipline post-déploiement

Gestion et fiabilité des tests instables (flaky)

Détecter et mettre en quarantaine : Suivre l’instabilité des tests dans le temps ; mettre en quarantaine les tests connus pour être instables et ne pas bloquer les livraisons à cause d’eux tout en priorisant leurs corrections.
Délais d’attente (timeouts) et nouvelles tentatives (retries) : Ajouter des délais d’attente raisonnables ; autoriser une seule nouvelle tentative pour les instabilités suspectées d’origine infrastructurelle, et non pour les échecs logiques.
Builds hermétiques : Éviter les appels réseau dans les tests unitaires ; figer (pin) les artéfacts et utiliser des émulateurs pour réduire le non-déterminisme.
Parallélisation : Répartir (shard) les tests dans Cloud Build sur plusieurs étapes ou workers pour minimiser la latence de la rétroaction.

Boucles de rétroaction

Déclencheurs de CI : Exécuter les tests unitaires et d’intégration à chaque commit sur la branche main et sur les pull requests. Utiliser des étapes Cloud Build distinctes pour que l’historique du build identifie l’étape défaillante. Créer des déclencheurs de livraison (release triggers) sur les tags Git, et non à chaque commit, pour contrôler les déploiements.
Vérification progressive : Promouvoir automatiquement de l’environnement de développement (dev) à celui de test après un déploiement réussi en s’abonnant aux notifications Pub/Sub de Cloud Deploy et en invoquant la promotion sur les événements SUCCEEDED.
Promotion basée sur les métriques : Pour les déploiements canary, conditionner l’augmentation du trafic aux métriques de Cloud Monitoring et aux SLO.

Documentation des livraisons, responsabilités et vérification post-déploiement

Documentation : Maintenir les notes de version (release notes), les guides opérationnels (runbooks) et les procédures de restauration (rollback) à proximité du code. Suivre les tickets de changement avec des liens vers les commits, les images et les versions d’environnement.
Responsabilités (Ownership) : Définir les rotations d’astreinte et les propriétaires de composants ; imposer l’utilisation de CODEOWNERS pour les zones sensibles. S’assurer que les approbateurs pour les promotions en production sont clairement identifiés.
Vérification post-déploiement : Exécuter les suites de tests de fumée (smoke tests), s’assurer que les budgets d’erreurs restent sains et vérifier les tableaux de bord par tag de version. Confirmer que les rapports de sécurité et de vulnérabilité restent conformes à la politique. En cas de problème, effectuer une restauration (roll back) d’abord, puis analyser la cause racine.

Scénario de problème pratique

L’équipe plateforme d’Acme Retail standardise les tests et les livraisons pour une application de microservices basée sur GKE qui inclut également un frontend web sans état (stateless) sur Cloud Run. Ils doivent garantir une rétroaction rapide, bloquer les builds à risque et déployer de nouvelles fonctionnalités en toute sécurité tout en utilisant le trafic en direct pour évaluer les performances.

Approche

Séparer les étapes de build et de test dans Cloud Build

Justification : Utiliser des étapes distinctes pour compiler, exécuter les tests unitaires, construire le conteneur et exécuter les tests d’intégration, afin que l’historique du build identifie précisément la phase défaillante et que les développeurs obtiennent rapidement une rétroaction exploitable.
Exemple :

steps:
- name: gcr.io/cloud-builders/docker
  args: ['build', '-t', '$IMAGE', '.']
- name: gcr.io/cloud-builders/gcloud
  args: ['bash','-lc','make unit']
- name: gcr.io/cloud-builders/gcloud
  args: ['bash','-lc','make integration']  # against emulators
images: ['$IMAGE']

Exécuter les tests d’intégration sur des émulateurs et des espaces de noms éphémères

Justification : Pour les workers Pub/Sub et les services s’appuyant sur Firestore, utiliser les émulateurs Pub/Sub et Firestore ; pour les services nécessitant des politiques de cluster, créer un espace de noms GKE éphémère par build avec des topics et des comptes de service temporaires via Workload Identity. Cela offre isolation, rapidité et faible coût tout en maintenant la fidélité.

Appliquer des portes de qualité (quality gates) de sécurité avec Artifact Registry et Binary Authorization

Justification : Activer l’analyse de vulnérabilités lors du push de l’image, faire échouer le pipeline en cas de CVE critiques et exiger des attestations dans Binary Authorization avant de déployer sur GKE. Cela empêche le déploiement d’images contenant des vulnérabilités critiques connues.

Utiliser des déclencheurs de livraison basés sur les tags Git

Justification : Les déclencheurs Cloud Build sur les tags (par exemple, vX.Y.Z) permettent des livraisons automatisées uniquement pour les commits explicitement tagués, évitant ainsi les déploiements accidentels en production à partir de chaque commit sur la branche main.

Déploiement progressif avec Cloud Deploy et Anthos Service Mesh

Justification : Définir un pipeline Cloud Deploy avec des cibles de développement (dev), de test et de production (prod). Utiliser une approbation manuelle pour conditionner la promotion vers la production. Pour la production, utiliser une stratégie canary avec ASM pour basculer 5 %, 25 %, 50 %, 100 % du trafic tout en surveillant les SLO. Cloud Deploy s’abonne à des hooks de vérification ; un échec interrompt ou restaure automatiquement le canary via l’API.

Observabilité et hooks de restauration (rollback) automatisés

Justification : Exporter les métriques Prometheus vers Cloud Monitoring et créer des métriques basées sur les journaux pour les signatures d’erreurs. Configurer des politiques d’alerte sur les métriques étiquetées par version. Une Cloud Function abonnée aux alertes appelle l’API Cloud Deploy pour suspendre ou restaurer le déploiement. Cela relie les signaux de santé objectifs au contrôle du déploiement.

Trafic fantôme (shadow traffic) et validation A/B pour le frontend Cloud Run

Justification : Utiliser la duplication de requêtes (request mirroring) au niveau de l’équilibreur de charge HTTP(S) externe pour envoyer les requêtes de production à la nouvelle révision Cloud Run sans impacter les utilisateurs. Ensuite, utiliser la répartition de trafic (traffic-splitting) de Cloud Run pour basculer de faibles pourcentages et comparer les métriques de latence/erreur avant le basculement complet.

Déploiement bleu-vert (blue-green) comme solution de repli pour les services backend critiques

Justification : Pour les services nécessitant une restauration instantanée, maintenir des déploiements bleu et vert derrière un seul service backend. Valider le déploiement vert avec des tests de fumée (smoke tests) et de contrat, puis basculer le trafic. Revenir en arrière instantanément si des anomalies apparaissent.

Vérification et documentation post-déploiement

Justification : Après la promotion, exécuter des tests de fumée automatisés, vérifier les tableaux de bord par version de livraison et mettre à jour les notes de version avec les digests des artéfacts et l’historique du déploiement. Les responsables et l’équipe d’astreinte reçoivent le transfert de responsabilités ; si les budgets d’erreurs sont consommés, effectuer d’abord une restauration, puis mener une analyse sans blâme (blameless analysis).

Cette approche fournit une rétroaction rapide et fiable en CI, impose la sécurité et la qualité, et utilise des stratégies de déploiement sûres et observables qui prennent en charge à la fois les expérimentations basées sur les attributs et la restauration instantanée en cas de besoin.

← Performance · Tous les domaines · Coûts →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →