APRENDER. PRATICAR. EVOLUIR.Identificar quem executa cada etapa
Um deployment passa por várias identidades. Regista quem inicia o processo, quem executa o build, quem publica a revisão e quem lê dados durante o runtime. Num build Cloud Build invocado por trigger, a service account definida no trigger é usada; o campo serviceAccount do ficheiro de configuração não a substitui. No exercício, build-release tem acesso ao repositório, mas o trigger usa build-trigger: rever apenas o YAML deixa a causa por resolver. Para Cloud Run, separa a conta de deploy da identidade de serviço configurada. Uma consegue criar a revisão sem que a outra consiga ler o bucket necessário. Prepara uma matriz identidade, ação, recurso e evidência. Durante suporte, segue a identidade efetiva da chamada recusada e ajusta apenas o acesso necessário à tarefa aprovada. Não uses o sucesso de uma etapa como prova de autorização das seguintes.
Seguir a origem de credenciais da aplicação
Application Default Credentials procura primeiro GOOGLE_APPLICATION_CREDENTIALS, depois o ficheiro local ADC conhecido e só depois a conta associada disponibilizada pelo metadata server. O exercício descreve uma configuração antiga válida dentro da imagem. Mesmo com run-current associada, essa origem anterior pode explicar a identidade antiga nos logs. A correção passa por remover a origem indevida e verificar a identidade usada pela revisão corrigida. Não aumentes permissões da conta errada para esconder a discrepância. Também não confundas gcloud auth login no portátil com a configuração ADC dentro do serviço: são contextos e credenciais diferentes. Na revisão da imagem, procura referências a credenciais e configuração de ambiente, sem expor valores sensíveis no ticket. Documenta a origem esperada, a observada e a validação posterior. A pergunta não assume que um ficheiro inválido provoca fallback; o caso usa explicitamente um ficheiro válido.
Ligar o artefacto testado ao artefacto publicado
Uma tag pode mudar de conteúdo entre duas decisões. Em Cloud Run, o deploy resolve a tag para um digest, e essa revisão continua a servir o digest resolvido. Mover release de D1 para D2 não altera a revisão R1 já criada; criar outra revisão a partir da tag pode selecionar D2. No exercício, a aprovação refere D1, mas candidate passou a D2 antes do deploy. Compara digest testado, digest aprovado e digest efetivo antes de atribuir tráfego. Se forem diferentes, não transfiras automaticamente a aprovação: usa o artefacto aprovado ou volta a testar e aprovar a alternativa. Uma tag com o mesmo nome não demonstra equivalência. Esta disciplina ajuda a investigação posterior porque permite relacionar cada resultado com conteúdo identificável. Guarda ainda a configuração relevante da revisão; fixar a imagem não prova que permissões e dependências funcionam no destino.
Fixar dependências e executar o plano revisto
Em Terraform, .terraform.lock.hcl regista a seleção dos providers; não fixa versões de módulos remotos. Para um módulo do Registry, uma constraint ampla permite outra versão elegível numa inicialização limpa. Usa uma versão exata quando a decisão exige reproduzir a seleção aprovada e conserva a revisão dessa alteração. Há outra fronteira no apply: sem ficheiro de plano, o comando calcula um plano novo. Ter approved.tfplan no diretório não faz com que seja escolhido automaticamente. Se a equipa aprovou esse artefacto, o passo seguinte deve consumi-lo explicitamente, com os controlos de contexto aplicáveis. Se é necessário voltar a planear, revê o novo resultado. auto-approve dispensa uma confirmação, não demonstra que o resultado novo corresponde ao anterior. No exercício, identifica separadamente a versão do módulo, o lock dos providers, o plano revisto e o comando que o processo pretende executar.
Controlar retries e conflitos de estado
As camadas de retry podem multiplicar pedidos. No modelo fictício, quatro tentativas totais do wrapper e dois pedidos totais por chamada da biblioteca permitem oito pedidos se todos falharem e nenhum prazo terminar antes. Os números já incluem a primeira tentativa. Define responsabilidade pelos retries, limite total de duração e comportamento da biblioteca. Para erros transitórios e operações que podem ser repetidas em segurança, usa a estratégia adequada com backoff e jitter; não repitas indiscriminadamente todas as falhas. Uma resposta 412 numa atualização protegida por generation e metageneration indica que a condição esperada não se verificou. Lê o estado, reconcilia a intenção e só então prepara outra atualização condicional, se continuar válida. Retirar as condições para obter sucesso elimina a proteção. Trocar apenas os números pelos mais recentes, mantendo conteúdo antigo, também pode esconder uma escrita concorrente que precisava de ser considerada.
Interpretar conclusão assíncrona e promoção de dados
Uma resposta HTTP de sucesso à consulta de uma operação não prova que o trabalho assíncrono terminou bem. Num recurso Operation, done=false indica trabalho em curso; done=true pode trazer error em vez de response. O excerto sintético da pergunta tem HTTP 200 e um erro de permissão no corpo. A automação deve guardar a falha e bloquear a etapa que exige sucesso, sem inventar que mais polling a vai corrigir. Noutra decisão, a promoção de uma migração contínua MySQL em Database Migration Service deixa de ler a origem e não pode ser interrompida ou anulada depois de começar. Um plano baseado num botão Undo inexistente não é um plano de recuperação. Define antes como tratar dados e novas escritas se a aceitação falhar. Confirma requisitos de paragem de escritas e alterações pendentes antes de atravessar essa fronteira.
Separar consumo, picos e autorização da pessoa
Em Apigee, uma quota diária responde a um acordo de consumo, mas não demonstra que o backend aguenta toda essa utilização concentrada em segundos. SpikeArrest permite tratar picos, mantendo uma Quota separada para o limite acordado. Evita prometer um teto distribuído exato sem analisar a configuração e as condições aplicáveis. Há outra separação no acesso: uma consumer key identifica a aplicação. Se dois utilizadores apresentam a mesma key e têm direitos diferentes sobre a conta A, validar apenas essa key não distingue esses direitos. O desenho precisa de identidade de utilizador autenticada e de uma decisão de autorização para o recurso. Rodar a key partilhada não resolve essa diferença. No exercício de revisão, desenha três perguntas: a aplicação pode chamar, a pessoa pode consultar esta conta e o ritmo é aceitável para o serviço. Cada pergunta precisa do seu controlo e evidência.
Preparar uma decisão de release sustentada
Gemini Cloud Assist pode ajudar a investigar ou propor configuração, mas a plausibilidade da resposta não substitui validação. Confere comandos, permissões e pressupostos com documentação e estado efetivo; revê o diff e ensaia no âmbito adequado antes do processo normal de mudança. No caso final, há duas falhas independentes: D2 não tem a aprovação de D1 e runtime-reader não consegue ler o bucket. A revisão ainda está isolada, sem tráfego de clientes. Suspende a promoção até resolver ambas. Como exercício, entrega uma pequena matriz com lacuna, evidência necessária, responsável e condição para avançar. Uma alternativa é testar e aprovar D2; outra é usar D1. Em qualquer delas, verifica o acesso de runtime. Estes são cenários originais e excertos sintéticos apoiados em documentação; não representam execução de ferramentas Google, Terraform ou Apigee, nem procedimentos internos de uma instituição financeira.
Uma revisão isolada contém um digest diferente do testado e a conta de runtime falha a leitura de dados, apesar do sucesso da conta de deploy.
Armadilhas comuns
Confundir deployer com runtime, tag com digest, provider lock com versão do módulo e HTTP 200 com sucesso da operação assíncrona.
Tópicos relacionados: Identidade e permissões · Reprodutibilidade de releases · Contratos de APIs
Identifica o artefacto, a identidade e o estado efetivos em cada etapa; a aprovação deve corresponder ao que vai realmente executar.
Referência: Run builds with a user-managed service account · Current linked standard guide; edition date unconfirmed (2026-09-30 inspection)