Google PCD: Testes, Engenharia de Qualidade e Gerenciamento de Lançamentos Seguros — Guia de estudos

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

Faz parte do Google Professional Cloud Developer — Guia de estudos. Pratique com respostas verificadas no centro de exames da Google, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

Equipes de alta velocidade no Google Cloud combinam testes rigorosos com entrega progressiva para reduzir riscos e, ao mesmo tempo, acelerar as mudanças. Uma estratégia robusta abrange desde testes unitários até testes de ponta a ponta, simulação realista de dados e dependências, quality gates automatizados e padrões de lançamento controlado, como canary e blue-green. Observabilidade, propriedade (ownership) e verificação disciplinada pós-lançamento fecham o ciclo. Esta seção detalha como projetar para confiabilidade, isolar riscos e promover builds com segurança entre ambientes usando os serviços do Google Cloud.

Estratégia de Teste e Gerenciamento de Dados

Pirâmide de testes e tipos de teste

Testes unitários: Verificação rápida e isolada de funções, classes e pequenos módulos. Devem ser a maior parte da suíte de testes. Execute-os em cada commit e pull request.
Testes de integração: Validam interações entre componentes, como a aplicação e seu datastore ou fila. Use os emuladores do Google Cloud quando disponíveis.
Testes de contrato: Contratos orientados ao consumidor (consumer-driven contracts) para microsserviços evitam alterações que quebrem a API. Valide o comportamento do provedor em relação ao esquema e à semântica esperados pelo consumidor antes da integração. Use Pact ou ferramentas semelhantes; versione sua API e publique os esquemas.
Testes de ponta a ponta (end-to-end): Exercitam o caminho completo do sistema usando configuração, identidade e políticas de rede semelhantes às de produção. Limite o número deles, paralelize e execute em ambientes de pré-produção.
Smoke tests: Verificações mínimas que confirmam se as dependências críticas, rotas e health checks se comportam corretamente após cada implantação. São sua primeira verificação pós-implantação.

Gerenciamento de dados de teste, isolamento, reprodutibilidade e paridade de ambientes

Preenchimento de dados (Data seeding): Gere conjuntos de dados pequenos e determinísticos para testes unitários e conjuntos de dados maiores e representativos para integração/desempenho. Preencha a partir de fixtures versionados no controle de código-fonte.
Isolamento: Garanta que os testes não compartilhem estado. Use bancos de dados efêmeros, namespaces isolados no GKE e prefixos únicos para objetos do Cloud Storage. Para SQL, crie esquemas por teste; para o Pub/Sub, gere tópicos/inscrições temporários.
Reprodutibilidade: Fixe as versões das dependências, torne os builds herméticos e fixe as sementes aleatórias (random seeds). Armazene os contêineres de teste com seus digests no Artifact Registry.
Paridade de ambientes: Padronize as imagens de contêiner e a infraestrutura como código entre os ambientes de desenvolvimento, QA, homologação (staging) e produção. Mantenha a configuração fora das imagens e use metadados e segredos específicos do ambiente. Para o Compute Engine, armazene valores por implantação nos metadados do modelo de instância; para paridade entre projetos, configure uma chave de metadados de ambiente e leia-a na inicialização para selecionar a configuração específica do ambiente.

Mocks, emuladores, fakes e serviços de sandbox

Mocks/stubs: Substitua colaboradores no nível unitário para isolar a lógica e eliminar chamadas de rede. Evite o uso excessivo de mocks; faça asserções sobre o comportamento, não sobre os detalhes da implementação.
Emuladores: Prefira os emuladores oficiais para testes de integração. Exemplos: emuladores do Firestore/Datastore, Pub/Sub, Spanner e Bigtable. Eles fornecem fidelidade de API sem custos na nuvem e aceleram a CI.
Fakes: Quando não houver um emulador, execute fakes locais e leves (por exemplo, um fake de object store) ou serviços de sandbox compartilhados com forte isolamento e cotas.
Simulação de dependências externas: Para APIs de terceiros, execute fakes baseados em contrato por trás de uma malha de serviços (service mesh) ou API gateway; configure timeouts, novas tentativas (retries) e injeção de caos para testar o tratamento de falhas.

Modos de falha comuns e trade-offs

A dependência excessiva de testes de ponta a ponta retarda a iteração; invista em testes unitários e de contrato para detectar problemas mais cedo.
Ambientes de teste compartilhados e de longa duração acumulam desvios (drift) e poluição de dados. Prefira ambientes efêmeros e configuração/desmontagem idempotente.
Os emuladores podem não espelhar perfeitamente a produção. Use testes E2E em estágios com serviços reais antes da promoção.

Exemplo curto do Cloud Build para separar estágios com falha

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

Etapas separadas garantem que o histórico de build identifique se a falha ocorreu na compilação/testes unitários, no build ou na integração.

Testes Não Funcionais e Qualidade de Código

Testes de desempenho

Tipos: Testes de carga (estado estável), estresse (além do pico), imersão (longa duração) e capacidade.
Ferramentas: Use o Cloud Monitoring para SLOs e alertas, o Cloud Trace para análise detalhada de latência e o Cloud Profiler para identificar os caminhos mais executados (hot paths). Para o GKE, escale com o Cluster Autoscaler e o HPA; para workers do Pub/Sub, o HPA em métricas externas lida com o escalonamento impulsionado por picos.
Testes em produção: Use dark launches e espelhamento de requisições (request mirroring) para avaliar novos backends com tráfego de produção de forma segura. O External HTTP(S) Load Balancing suporta espelhamento de requisições; o Anthos Service Mesh suporta traffic shadowing.

Testes de segurança

SAST/verificação de segredos: Execute analisadores estáticos na CI e rejeite credenciais codificadas (hard-coded). Armazene segredos no Secret Manager com acesso de privilégio mínimo.
Verificação de dependências e imagens: Habilite o Container Analysis no Artifact Registry. Imponha políticas com o Binary Authorization, exigindo atestados de que não existem vulnerabilidades críticas antes da implantação.
DAST: Verifique ambientes de homologação (staging) com scanners autenticados e bloqueie os lançamentos em caso de descobertas críticas.

Acessibilidade e regressão

Acessibilidade: Integre verificações automatizadas de acessibilidade (a11y) (por exemplo, Lighthouse CI) em verificações de pré-merge não bloqueantes; corrija antes do lançamento.
Suítes de regressão: Mantenha suítes de regressão curadas e estáveis para jornadas críticas. Execute smoke tests em cada implantação e a regressão completa em candidatos a lançamento (release candidates).

Análise estática, quality gates e revisão de código

Análise estática: Configure linters e formatadores apropriados para a linguagem como verificações de pré-envio (pre-submit). Use o Bazel ou similar para paralelizar.
Quality gates: Falhe os builds em caso de violação de limites (cobertura, complexidade, erros de lint). Publique os resultados nos logs do Cloud Build.
Revisão de código: Exija revisão por duas pessoas para alterações de risco, CODEOWNERS para caminhos críticos e CI de pré-envio (presubmit) em tags usadas para lançamentos.
Supply chain: Gere SBOMs, assine artefatos e armazene a proveniência. Imponha verificações de atestado no Binary Authorization.

Entrega Progressiva e Lançamentos Seguros

Estratégias de implantação

Rolling: Substitui pods ou instâncias incrementalmente. Baixo risco para serviços sem estado (stateless); combine com sondas de prontidão (readiness probes) e configurações de surge/disponibilidade.
Blue-green: Implanta um ambiente novo completo, executa a verificação e depois vira o tráfego. Permite reversão (rollback) instantânea ao reverter o balanceador de carga. Ideal quando você precisa de um fallback imediato.
Canary: Desvia gradualmente uma pequena porcentagem do tráfego para a nova versão enquanto monitora métricas-chave. Promova automaticamente se estiver saudável; reverta em caso de regressões.
Divisão de tráfego (Traffic splitting): Roteia por porcentagem ou atributos (cabeçalhos, cookies, user-agent) com o GKE mais o Anthos Service Mesh, ou use a divisão nativa no Cloud Run e no App Engine.

Feature flags e experimentação

Feature flags: Desacopla a implantação (deploy) do lançamento (release). Use flags para lançamento gradual, interruptores de desativação (kill switches) e alternadores de experimentos. Armazene de forma centralizada (por exemplo, um serviço gerenciado de flags ou um repositório de configuração protegido pelo IAM). Mantenha os ciclos de vida das flags curtos e remova o que não for mais usado.
Dark launches: Implanta funcionalidades desativadas; valide através de usuários internos ou tráfego sintético.
Tráfego espelhado (Shadow traffic): Espelha as requisições de produção para novos serviços sem impactar os usuários; compare as respostas para detectar regressões.
Experimentos controlados: Implemente roteamento A/B ou multivariado com regras de malha de serviço (service mesh). Para experimentos baseados em user-agent, roteie por correspondência de cabeçalho (header).

Gates, aprovações, rollback e observabilidade

Gates de implantação (Deployment gates): Adicione testes de integração pré-implantação e verificações de fumaça/saúde (smoke/health checks) pós-implantação. Para promoção entre ambientes, use gatilhos baseados em tags para separar a compilação (build) do lançamento (release).
Aprovações manuais: Exija aprovação humana em marcos importantes, como da homologação (staging) para a produção. O Cloud Deploy suporta etapas de aprovação manual por alvo (target).
Rollback automático: Defina SLOs e políticas de alerta; quando um canary viola os limiares de taxa de erro ou latência, reverta automaticamente invocando a API de implantação. Mantenha os rollbacks rápidos e bem praticados.
Observabilidade de lançamentos: Instrumente os lançamentos com rótulos (labels) de versão em métricas e logs. Exporte as métricas do Prometheus para o Cloud Monitoring e crie métricas baseadas em logs para padrões de erro para correlacionar a telemetria de forma econômica.

Exemplo curto de roteamento do ASM para canary baseado em cabeçalho

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

Confiabilidade de Testes, Ciclos de Feedback e Disciplina Pós-lançamento

Gerenciamento e confiabilidade de testes instáveis (flaky tests)

Detectar e colocar em quarentena: Monitore a instabilidade dos testes ao longo do tempo; coloque em quarentena testes conhecidos como instáveis e não bloqueie lançamentos por causa deles, enquanto prioriza as correções.
Timeouts e novas tentativas (retries): Adicione timeouts razoáveis; permita uma única nova tentativa para suspeitas de falhas de infraestrutura, não para falhas de lógica.
Builds herméticos: Evite chamadas de rede em testes unitários; fixe as versões dos artefatos e use emuladores para reduzir o não determinismo.
Paralelização: Fragmente os testes no Cloud Build em múltiplos passos ou workers para minimizar a latência do feedback.

Ciclos de feedback

Gatilhos de CI: Execute testes unitários e de integração a cada commit na branch main e em pull requests. Use passos separados no Cloud Build para que o histórico do build identifique o estágio que falhou. Crie gatilhos de release em tags do Git, não em cada commit, para controlar as implantações.
Verificação progressiva: Promova automaticamente de dev para test após uma implantação bem-sucedida, inscrevendo-se nas notificações Pub/Sub do Cloud Deploy e invocando a promoção em eventos SUCCEEDED.
Promoção baseada em métricas: Para implantações canário, controle o aumento gradual do tráfego com base em métricas do Cloud Monitoring e SLOs.

Documentação de release, responsabilidade e verificação pós-lançamento

Documentação: Mantenha notas de release, runbooks e procedimentos de rollback junto ao código. Rastreie os tickets de mudança com links para commits, imagens e versões de ambiente.
Responsabilidade (Ownership): Defina rotações de plantão e proprietários de componentes; imponha o uso de CODEOWNERS para áreas sensíveis. Garanta que haja aprovadores claros para promoções para produção.
Verificação pós-lançamento: Execute suítes de smoke tests, garanta que os orçamentos de erro permaneçam saudáveis e verifique os dashboards pela tag de versão. Confirme que os relatórios de segurança e vulnerabilidade permanecem dentro da política. Se surgirem problemas, reverta primeiro (rollback) e depois analise a causa raiz.

Cenário de Problema Prático

A equipe de plataforma da Acme Retail está padronizando os testes e lançamentos para uma aplicação de microsserviços baseada em GKE que também inclui um frontend web stateless no Cloud Run. Eles precisam garantir feedback rápido, bloquear builds de risco e lançar novas funcionalidades de forma segura, usando tráfego real para avaliar o desempenho.

Abordagem

Separar os estágios de build e teste no Cloud Build

Justificativa: Use passos distintos para compilar, executar testes unitários, construir o contêiner e executar testes de integração, para que o histórico do build identifique a fase que falhou e os desenvolvedores recebam feedback acionável rapidamente.
Exemplo:

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

Executar testes de integração com emuladores e namespaces efêmeros

Justificativa: Para workers do Pub/Sub e serviços que usam o Firestore, utilize os emuladores do Pub/Sub e do Firestore; para serviços que exigem políticas de cluster, crie um namespace efêmero no GKE por build com tópicos e contas de serviço temporárias via Workload Identity. Isso proporciona isolamento, velocidade e baixo custo, mantendo a fidelidade.

Impor quality gates de segurança com o Artifact Registry e o Binary Authorization

Justificativa: Habilite a verificação de vulnerabilidades no push da imagem, falhe o pipeline em caso de CVEs críticos e exija atestados no Binary Authorization antes de implantar no GKE. Isso impede a implantação de imagens com vulnerabilidades críticas conhecidas.

Usar gatilhos de release baseados em tags do Git

Justificativa: Gatilhos do Cloud Build em tags (por exemplo, vX.Y.Z) permitem releases automatizados apenas para commits explicitamente marcados com tags, evitando implantações acidentais em produção a cada commit na branch main.

Entrega progressiva com Cloud Deploy e Anthos Service Mesh

Justificativa: Defina um pipeline do Cloud Deploy com alvos de dev, test e prod. Use aprovação manual para controlar a promoção para prod. Para prod, use uma estratégia canário com o ASM para desviar 5%, 25%, 50%, 100% do tráfego enquanto monitora os SLOs. O Cloud Deploy se inscreve em hooks de verificação; uma falha interrompe ou reverte o canário automaticamente via API.

Observabilidade e hooks de rollback automatizados

Justificativa: Exporte métricas do Prometheus para o Cloud Monitoring e crie métricas baseadas em logs para assinaturas de erro. Configure políticas de alerta em métricas rotuladas por versão. Uma Cloud Function inscrita nos alertas chama a API do Cloud Deploy para pausar ou reverter o rollout. Isso conecta sinais objetivos de saúde ao controle da implantação.

Tráfego espelhado (shadow traffic) e validação A/B para o frontend no Cloud Run

Justificativa: Use o espelhamento de requisições no balanceador de carga HTTP(S) externo para enviar requisições de produção para a nova revisão do Cloud Run sem impactar os usuários. Em seguida, use a divisão de tráfego do Cloud Run para desviar pequenas porcentagens e comparar métricas de latência/erro antes da transição completa.

Fallback blue-green para serviços de backend críticos

Justificativa: Para serviços que exigem rollback instantâneo, mantenha implantações blue e green por trás de um único serviço de backend. Valide a implantação green com smoke tests e testes de contrato, e então inverta o tráfego. Reverta instantaneamente se anomalias aparecerem.

Verificação e documentação pós-lançamento

Justificativa: Após a promoção, execute smoke tests automatizados, verifique os dashboards pela versão do release e atualize as notas de release com os digests dos artefatos e o histórico do rollout. A responsabilidade e a equipe de plantão recebem o bastão; se os orçamentos de erro forem consumidos, reverta primeiro e, em seguida, conduza uma análise sem culpa.

Essa abordagem entrega feedback rápido e confiável no CI, impõe segurança e qualidade, e usa estratégias de rollout seguras e observáveis que suportam tanto experimentos baseados em atributos quanto rollback instantâneo quando necessário.

← Desempenho · Todos os domínios · Custos →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →