Questão de Engenharia de Software — Geral — FCC 2025

GitLab CI/CD: controle manual de deployments em produção

Gabarito: letra A. Para tornar os deployments de produção sempre manuais no GitLab CI/CD, a mudança adequada é adicionar uma stage de produção com when: manual — essa palavra-chave faz o job aguardar a aprovação humana antes de executar, mesmo que os testes tenham passado automaticamente. É a forma nativa do GitLab de exigir intervenção manual em um ponto do pipeline.

O GitLab CI/CD é uma ferramenta de integração e entrega contínua que automatiza o build, os testes e o deploy por meio de pipelines definidos em um arquivo .gitlab-ci.yml. Cada pipeline é composto por stages (estágios) e jobs (tarefas), e cada job pode ter regras de execução controladas pela diretiva when. Essa diretiva aceita valores como on_success (executa se os jobs anteriores tiveram sucesso), on_failure, always, never e manual. O valor manual é o que transforma o job em um gatilho humano: o pipeline pausa naquele estágio e só prossegue quando alguém clica no botão de execução manual na interface do GitLab. É exatamente o que a equipe precisa para garantir que nenhum deploy vá para produção sem uma aprovação explícita, independentemente do resultado dos testes automatizados.

A necessidade de aprovação manual em produção é uma prática comum em ambientes que exigem controle de risco e conformidade. Mesmo que a suíte de testes seja aprovada automaticamente, a decisão de liberar uma mudança para o ambiente de produção pode envolver critérios que a automação não captura — como impacto no negócio, janela de manutenção ou revisão de um responsável. O when: manual materializa esse controle no próprio pipeline, criando um ponto de verificação humano obrigatório.

A alternativa C (when: on_success) é o comportamento padrão do GitLab: o job executa automaticamente quando os jobs anteriores terminam com sucesso. Isso é o oposto do que se deseja — o deploy continuaria automático. A alternativa B (migrar para pipelines baseados em eventos de merge) não resolve o problema, pois eventos de merge apenas disparam o pipeline; não introduzem aprovação manual. A alternativa D (usar a branch develop para deploy automático) pioraria a situação, pois automatizaria ainda mais o deploy. A alternativa E (configurar runners para ignorar falhas de deploy) é contraproducente: ignorar falhas não torna o deploy manual, apenas mascara erros.

A pegadinha da banca está em confundir o candidato com termos que parecem relacionados, mas não atendem ao requisito de "deploy manual". O when: manual é a única diretiva que cria uma barreira humana no pipeline. Guarde essa distinção: on_success = automático; manual = exige clique humano. É nela que as alternativas se dividem.

Alternativa A — ✅ Correta ⟵ GABARITO

A alternativa A está correta porque when: manual é a diretiva do GitLab CI que torna um job manual. Ao adicionar essa diretiva à stage de produção, o pipeline será pausado antes do deploy, aguardando que um operador autorize a execução. Isso atende exatamente ao requisito do enunciado: deployments para produção sempre manuais, mesmo após a aprovação automática dos testes. O job só será executado quando alguém clicar em "play" na interface do GitLab.

Alternativa B — ❌ Incorreta

Migrar para pipelines baseados em eventos de merge não introduz controle manual. Eventos de merge apenas definem quando o pipeline é disparado (por exemplo, quando um merge request é aceito). O deploy continuaria automático após o merge, sem exigir aprovação humana. A banca usa esse distrator para testar se o candidato sabe que o gatilho do pipeline não é o mesmo que controle de execução.

Alternativa C — ❌ Incorreta

when: on_success é o comportamento padrão do GitLab: o job executa automaticamente quando os jobs anteriores terminam com sucesso. Isso manteria o deploy automático, exatamente o que a equipe quer evitar. A pegadinha aqui é que on_success parece "correto" porque os testes passaram, mas ele não adiciona nenhuma barreira manual — é o oposto do que se deseja.

Alternativa D — ❌ Incorreta

Usar a branch develop para deploy automático não só não resolve o problema, como o agrava: automatizaria o deploy a partir de uma branch de desenvolvimento, aumentando o risco de erros em produção. A branch develop é tipicamente usada para integração contínua, não para deploy em produção. A banca explora a confusão entre fluxo de branches e controle de deploy.

Alternativa E — ❌ Incorreta

Configurar runners para ignorar falhas de deploy é contraproducente e não tem relação com tornar o deploy manual. Ignorar falhas (allow_failure) apenas impede que o pipeline falhe quando um job falha; não adiciona aprovação humana. Pelo contrário, isso reduziria a segurança do processo, mascarando erros em vez de exigir intervenção.

Gabarito: letra A