Google PCD: Pruebas, ingeniería de calidad y gestión de lanzamientos seguros — Guía de estudio

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

Forma parte de la Google Professional Cloud Developer — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Google, o realiza tests cronometrados en ExamRoll.io.

Descripción general

Los equipos de alta velocidad en Google Cloud combinan pruebas rigurosas con la implementación progresiva para reducir el riesgo mientras aceleran el cambio. Una estrategia sólida abarca desde pruebas unitarias hasta pruebas de extremo a extremo, simulación realista de datos y dependencias, puertas de calidad automatizadas y patrones de lanzamiento controlados como canary y blue-green. La observabilidad, la propiedad (ownership) y la verificación disciplinada posterior al lanzamiento cierran el ciclo. Esta sección detalla cómo diseñar para la fiabilidad, aislar el riesgo y promover compilaciones (builds) de forma segura entre entornos con los servicios de Google Cloud.

Estrategia de pruebas y gestión de datos

Pirámide de pruebas y tipos de pruebas

Pruebas unitarias: Verificación rápida y aislada de funciones, clases y módulos pequeños. Deben dominar el conjunto de pruebas. Ejecútalas en cada commit y pull request.
Pruebas de integración: Validan las interacciones entre componentes, como la aplicación y su almacén de datos o cola. Usa los emuladores de Google Cloud cuando estén disponibles.
Pruebas de contrato: Los contratos dirigidos por el consumidor (consumer-driven contracts) para microservicios evitan cambios que rompan la API. Valida el comportamiento del proveedor contra el esquema y la semántica esperados por el consumidor antes de la integración. Usa Pact o herramientas similares; versiona tu API y publica los esquemas.
Pruebas de extremo a extremo: Ejercitan la ruta completa del sistema utilizando configuración, identidad y políticas de red similares a las de producción. Limita su número, paralelízalas y ejecútalas en entornos de preproducción.
Pruebas de humo (Smoke tests): Sondeos mínimos que confirman que las dependencias críticas, las rutas y las comprobaciones de estado (health checks) se comportan correctamente después de cada despliegue. Son tu primera verificación posterior a la implementación.

Gestión de datos de prueba, aislamiento, reproducibilidad y paridad de entornos

Siembra de datos (Data seeding): Genera conjuntos de datos pequeños y deterministas para pruebas unitarias y conjuntos de datos más grandes y representativos para pruebas de integración/rendimiento. Siembra a partir de fixtures registrados en el control de código fuente.
Aislamiento: Asegúrate de que las pruebas no compartan estado. Usa bases de datos efímeras, namespaces de GKE aislados y prefijos únicos para los objetos de Cloud Storage. Para SQL, crea esquemas por prueba; para Pub/Sub, genera temas/suscripciones temporales.
Reproducibilidad: Fija las versiones de las dependencias, haz que las compilaciones sean herméticas y fija las semillas aleatorias. Almacena los contenedores de prueba con sus digests en Artifact Registry.
Paridad de entornos: Estandariza las imágenes de contenedor y la infraestructura como código en los entornos de desarrollo, QA, staging y producción. Mantén la configuración fuera de las imágenes y usa metadatos y secretos específicos del entorno. Para Compute Engine, almacena los valores por despliegue en los metadatos de la plantilla de instancia; para la paridad entre proyectos, configura una clave de metadatos de entorno y léela al inicio para seleccionar la configuración específica del entorno.

Simulacros (mocking), emuladores, falsos (fakes) y servicios de sandbox

Mocks/stubs: Reemplaza los colaboradores a nivel unitario para aislar la lógica y eliminar las llamadas de red. Evita el exceso de mocking; haz aserciones sobre el comportamiento, no sobre los detalles de implementación.
Emuladores: Prefiere los emuladores oficiales para las pruebas de integración. Ejemplos: emuladores de Firestore/Datastore, Pub/Sub, Spanner y Bigtable. Proporcionan fidelidad de API sin costos de nube y aceleran la CI.
Falsos (Fakes): Cuando no existe un emulador, ejecuta fakes locales y ligeros (por ejemplo, un almacén de objetos falso) o servicios de sandbox compartidos con un fuerte aislamiento y cuotas.
Simulación de dependencias externas: Para las API de terceros, ejecuta fakes basados en contratos detrás de una malla de servicios (service mesh) o una puerta de enlace de API; configura tiempos de espera, reintentos e inyección de caos para probar el manejo de fallos.

Modos de fallo comunes y contrapartidas

La dependencia excesiva de las pruebas de extremo a extremo ralentiza la iteración; invierte en pruebas unitarias y de contrato para detectar problemas antes.
Los entornos de prueba compartidos y de larga duración acumulan desviaciones (drift) y contaminación de datos. Prefiere entornos efímeros y una configuración/desmontaje idempotente.
Los emuladores pueden no reflejar perfectamente la producción. Usa pruebas E2E en staging con servicios reales antes de la promoción a producción.

Ejemplo corto de Cloud Build para separar etapas que fallan

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']

Los pasos separados aseguran que el historial de compilación identifique si falló la compilación/pruebas unitarias, la construcción (build) o la integración.

Pruebas no funcionales y calidad del código

Pruebas de rendimiento

Tipos: Pruebas de carga (estado estable), de estrés (más allá del pico), de inmersión (soak, larga duración) y de capacidad.
Herramientas: Usa Cloud Monitoring para SLOs y alertas, Cloud Trace para el desglose de latencia y Cloud Profiler para identificar puntos calientes (hot paths). Para GKE, escala con Cluster Autoscaler y HPA; para los workers de Pub/Sub, el HPA sobre métricas externas maneja el escalado impulsado por picos.
Pruebas en producción: Usa lanzamientos oscuros (dark launches) y duplicación de solicitudes (request mirroring) para evaluar nuevos backends de forma segura con tráfico de producción. External HTTP(S) Load Balancing admite la duplicación de solicitudes; Anthos Service Mesh admite el traffic shadowing.

Pruebas de seguridad

SAST/escaneo de secretos: Ejecuta analizadores estáticos en CI y rechaza las credenciales codificadas (hard-coded). Almacena los secretos en Secret Manager con acceso de privilegio mínimo.
Escaneo de dependencias e imágenes: Habilita Container Analysis en Artifact Registry. Impón políticas con Binary Authorization, exigiendo atestaciones de que no existen vulnerabilidades críticas antes del despliegue.
DAST: Escanea los entornos de staging con escáneres autenticados y bloquea los lanzamientos si se encuentran hallazgos críticos.

Accesibilidad y regresión

Accesibilidad: Integra comprobaciones automatizadas de accesibilidad (a11y) (por ejemplo, Lighthouse CI) en las verificaciones previas a la fusión (pre-merge) que no bloqueen el proceso; remedia antes del lanzamiento.
Suites de regresión: Mantén suites de regresión seleccionadas y estables para los flujos críticos. Ejecuta pruebas de humo en cada despliegue y la regresión completa en los candidatos a lanzamiento (release candidates).

Análisis estático, puertas de calidad y revisión de código

Análisis estático: Configura linters y formateadores apropiados para el lenguaje como verificaciones previas al envío (pre-submit). Usa Bazel o similar para paralelizar.
Puertas de calidad: Falla las compilaciones si se superan los umbrales (cobertura, complejidad, errores de lint). Publica los resultados en los registros de Cloud Build.
Revisión de código: Exige la revisión por dos personas para cambios arriesgados, CODEOWNERS para las rutas críticas y CI previo al envío (presubmit) en las etiquetas (tags) utilizadas para los lanzamientos.
Cadena de suministro: Genera SBOMs, firma los artefactos y almacena la procedencia. Impón las comprobaciones de atestación en Binary Authorization.

Entrega progresiva y lanzamientos seguros

Estrategias de despliegue

Rolling (progresivo): Reemplaza pods o instancias de forma incremental. Bajo riesgo para servicios sin estado (stateless); combínalo con sondeos de preparación (readiness probes) y configuraciones de sobreaprovisionamiento/disponibilidad (surge/availability).
Blue-green (azul-verde): Levanta un entorno nuevo completo, ejecuta la verificación y luego cambia el tráfico. Permite una reversión (rollback) instantánea al revertir el balanceador de carga. Ideal cuando necesitas una recuperación inmediata.
Canary (canario): Desvía gradualmente un pequeño porcentaje del tráfico a la nueva versión mientras supervisas las métricas clave. Automatiza la promoción si el estado es saludable; revierte en caso de regresiones.
División de tráfico (Traffic splitting): Enruta por porcentaje o atributos (cabeceras, cookies, user-agent) con GKE y Anthos Service Mesh, o utiliza la división integrada en Cloud Run y App Engine.

Feature flags y experimentación

Feature flags: Desacopla el despliegue del lanzamiento. Usa los flags para lanzamientos graduales, interruptores de emergencia (kill switches) y para activar/desactivar experimentos. Almacénalos de forma centralizada (por ejemplo, un servicio gestionado de flags o un almacén de configuración protegido por IAM). Mantén la vida útil de los flags corta y elimina los que ya no se usan.
Lanzamientos oscuros (Dark launches): Despliega funcionalidades deshabilitadas; valídalas mediante usuarios internos o tráfico sintético.
Tráfico en la sombra (Shadow traffic): Replica las solicitudes de producción a los nuevos servicios sin impactar a los usuarios; compara las respuestas para detectar regresiones.
Experimentos controlados: Implementa enrutamiento A/B o multivariante con reglas de la malla de servicios (service mesh). Para experimentos basados en el user-agent, enruta por coincidencia de cabecera.

Puertas de enlace, aprobaciones, reversión y observabilidad

Puertas de enlace de despliegue (Deployment gates): Añade pruebas de integración previas al despliegue y verificaciones de estado/smoke tests posteriores. Para la promoción entre entornos, utiliza disparadores basados en etiquetas (tags) para separar la compilación (build) del lanzamiento (release).
Aprobaciones manuales: Requiere la aprobación de una persona en hitos clave, como el paso de staging a producción. Cloud Deploy admite pasos de aprobación manual por cada destino (target).
Reversión automática (Automatic rollback): Define SLOs y políticas de alertas; cuando un canario viola los umbrales de tasa de errores o latencia, revierte automáticamente invocando la API de despliegue. Mantén las reversiones rápidas y bien practicadas.
Observabilidad de lanzamientos: Instrumenta los lanzamientos con etiquetas de versión en métricas y registros. Exporta las métricas de Prometheus a Cloud Monitoring y crea métricas basadas en registros para patrones de error para correlacionar la telemetría de forma rentable.

Ejemplo corto de enrutamiento en ASM para un canario basado en cabeceras

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

Confiabilidad de las pruebas, bucles de retroalimentación y disciplina posterior al lanzamiento

Gestión y confiabilidad de las pruebas inestables (flaky tests)

Detectar y poner en cuarentena: Realiza un seguimiento de la inestabilidad de las pruebas a lo largo del tiempo; pon en cuarentena las pruebas que se sabe que son inestables y no bloquees los lanzamientos por ellas mientras se priorizan las correcciones.
Tiempos de espera y reintentos: Agrega tiempos de espera razonables; permite un único reintento para fallas sospechosas de infraestructura, no para fallas de lógica.
Compilaciones herméticas: Evita las llamadas de red en las pruebas unitarias; fija las versiones de los artefactos y usa emuladores para reducir el no determinismo.
Paralelización: Fragmenta las pruebas en Cloud Build en múltiples pasos o workers para minimizar la latencia de la retroalimentación.

Bucles de retroalimentación

Disparadores de CI: Ejecuta pruebas unitarias y de integración en cada confirmación (commit) a la rama principal y en las solicitudes de extracción (pull requests). Usa pasos separados en Cloud Build para que el historial de compilación identifique la etapa que falla. Crea disparadores de lanzamiento basados en etiquetas de Git (tags), no en cada confirmación, para controlar los despliegues.
Verificación progresiva: Promociona automáticamente de desarrollo a pruebas tras un despliegue exitoso suscribiéndote a las notificaciones de Pub/Sub de Cloud Deploy e invocando la promoción en eventos de tipo SUCCEEDED.
Promoción basada en métricas: Para los despliegues canary, condiciona el aumento gradual del tráfico a las métricas y SLO de Cloud Monitoring.

Documentación de lanzamientos, propiedad y verificación posterior al lanzamiento

Documentación: Mantén notas de la versión, runbooks y procedimientos de reversión (rollback) junto al código. Realiza un seguimiento de los tickets de cambio con enlaces a las confirmaciones (commits), imágenes y versiones del entorno.
Propiedad: Define rotaciones de guardia (on-call) y propietarios de componentes; impón el uso de CODEOWNERS para áreas sensibles. Asegúrate de que haya aprobadores claros para las promociones a producción.
Verificación posterior al lanzamiento: Ejecuta conjuntos de pruebas de humo (smoke suites), asegúrate de que los presupuestos de error se mantengan saludables y verifica los paneles de control por etiqueta de versión. Confirma que los informes de seguridad y vulnerabilidades se mantengan dentro de la política. Si surgen problemas, revierte primero y luego investiga la causa raíz.

Escenario de problema práctico

El equipo de plataforma de Acme Retail está estandarizando las pruebas y los lanzamientos para una aplicación de microservicios basada en GKE que también incluye un frontend web sin estado en Cloud Run. Deben garantizar una retroalimentación rápida, bloquear compilaciones de riesgo y desplegar nuevas características de forma segura mientras utilizan el tráfico en vivo para evaluar el rendimiento.

Enfoque

Separar las etapas de compilación y prueba en Cloud Build

Justificación: Usa pasos distintos para compilar, ejecutar pruebas unitarias, construir el contenedor y ejecutar pruebas de integración, de modo que el historial de compilación identifique la fase que falla y los desarrolladores obtengan retroalimentación procesable rápidamente.
Ejemplo:

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']

Ejecutar pruebas de integración contra emuladores y espacios de nombres efímeros

Justificación: Para los workers de Pub/Sub y los servicios respaldados por Firestore, usa los emuladores de Pub/Sub y Firestore; para los servicios que requieren políticas de clúster, crea un espacio de nombres efímero de GKE por cada compilación con temas y cuentas de servicio temporales a través de Workload Identity. Esto proporciona aislamiento, velocidad y bajo costo mientras se mantiene la fidelidad.

Imponer puertas de calidad de seguridad con Artifact Registry y Binary Authorization

Justificación: Habilita el escaneo de vulnerabilidades al subir una imagen, haz que la canalización falle si se encuentran CVE críticas y exige atestaciones en Binary Authorization antes de desplegar en GKE. Esto evita el despliegue de imágenes con vulnerabilidades críticas conocidas.

Usar disparadores de lanzamiento basados en etiquetas de Git

Justificación: Los disparadores de Cloud Build basados en etiquetas (por ejemplo, vX.Y.Z) permiten lanzamientos automatizados solo para confirmaciones (commits) etiquetadas explícitamente, evitando despliegues accidentales a producción desde cada confirmación a la rama principal.

Entrega progresiva con Cloud Deploy y Anthos Service Mesh

Justificación: Define una canalización de Cloud Deploy con destinos de desarrollo, pruebas y producción. Usa la aprobación manual para controlar la promoción a producción. Para producción, utiliza una estrategia canary con ASM para desviar el 5 %, 25 %, 50 %, 100 % del tráfico mientras se monitorean los SLO. Cloud Deploy se suscribe a los ganchos de verificación; un fallo detiene o revierte el canary automáticamente a través de la API.

Observabilidad y ganchos de reversión (rollback) automatizados

Justificación: Exporta métricas de Prometheus a Cloud Monitoring y crea métricas basadas en registros para las firmas de error. Configura políticas de alerta sobre métricas etiquetadas por versión. Una Cloud Function suscrita a las alertas llama a la API de Cloud Deploy para pausar o revertir el despliegue. Esto vincula las señales objetivas de salud con el control del despliegue.

Tráfico duplicado (shadow traffic) y validación A/B para el frontend de Cloud Run

Justificación: Usa la duplicación de solicitudes en el balanceador de carga HTTP(S) externo para enviar solicitudes de producción a la nueva revisión de Cloud Run sin afectar a los usuarios. Luego, utiliza la división de tráfico de Cloud Run para desviar pequeños porcentajes y comparar las métricas de latencia/error antes del cambio completo.

Respaldo azul-verde (blue-green) para servicios de backend críticos

Justificación: Para los servicios que requieren una reversión (rollback) instantánea, mantén despliegues azul y verde detrás de un único servicio de backend. Valida el despliegue verde con pruebas de humo y de contrato, y luego cambia el tráfico. Revierte instantáneamente si aparecen anomalías.

Verificación y documentación posterior al lanzamiento

Justificación: Después de la promoción, ejecuta pruebas de humo automatizadas, verifica los paneles de control por versión de lanzamiento y actualiza las notas de la versión con los resúmenes (digests) de los artefactos y el historial de despliegue. La propiedad y el equipo de guardia (on-call) reciben el traspaso; si los presupuestos de error se consumen, revierte primero y luego realiza un análisis post-mortem sin culpables.

Este enfoque proporciona retroalimentación rápida y confiable en CI, impone la seguridad y la calidad, y utiliza estrategias de despliegue seguras y observables que admiten tanto experimentos basados en atributos como reversiones instantáneas cuando es necesario.

← Rendimiento · Todos los dominios · Costo →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →