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

CI/CD: Pipelines Declarativos em GitHub Actions e GitLab CI

Gabarito: letra D. A abordagem tecnicamente adequada para automatizar build, testes e deploy a cada push na branch main é definir um arquivo de pipeline declarativo versionado no repositório, como .github/workflows/ci.yml (GitHub Actions) ou .gitlab-ci.yml (GitLab CI). Essas ferramentas são serviços de CI/CD integrados ao repositório Git que permitem a automação completa do ciclo de vida, desde builds até deploys, disparada por eventos como o push.

O enunciado descreve exatamente o que é Integração Contínua (CI) e Entrega Contínua (CD): a cada push na branch principal, o código é automaticamente compilado (build da imagem Docker), testado e preparado para implantação (publicação no registry e deploy em homologação). A CI é a prática de integrar código várias vezes ao dia, com compilação e testes automáticos; a CD prepara automaticamente as alterações para liberação, podendo incluir o deploy em ambiente de homologação. A chave da questão está em reconhecer que essa automação é declarada no próprio repositório, em um arquivo de configuração que descreve os jobs do pipeline — e não em scripts manuais, servidores dedicados com polling ou notificações por webhook.

O GitHub Actions e o GitLab CI são ferramentas de automação que leem um arquivo de configuração versionado no repositório. No GitHub, o arquivo fica em .github/workflows/ e define workflows com jobs e steps; no GitLab, o arquivo .gitlab-ci.yml define stages e jobs. Ambos são declarativos: você descreve o que deve acontecer (build, teste, deploy) e a ferramenta executa em runners. O pipeline é disparado por eventos do repositório, como push na branch main. Essa é a prática padrão de mercado e o que a banca espera como resposta.

A pegadinha da questão está em confundir CI/CD com práticas manuais ou semi-automatizadas. A alternativa que menciona webhooks, por exemplo, parece técnica, mas webhooks apenas notificam eventos — não executam build, testes ou deploy. A alternativa que menciona servidor dedicado com polling também não é a abordagem adequada, pois não aproveita a integração nativa da ferramenta de CI/CD com o repositório. A alternativa que menciona script local manual é o oposto da automação desejada. E a alternativa de homologação permanente com atualização manual também não atende ao requisito de automação a cada push.

O critério decisivo para separar as alternativas é: a automação deve ser declarada no repositório e executada automaticamente pela ferramenta de CI/CD, sem intervenção manual. Guarde isso: pipeline declarativo versionado = CI/CD; qualquer coisa que dependa de ação manual, polling ou notificação é abordagem inadequada.

Alternativa A — ❌ Incorreta

Executar periodicamente docker build em servidor dedicado, observando eventos de versionamento, é uma abordagem de polling (verificação periódica) que não aproveita a integração nativa da ferramenta de CI/CD com o repositório. O GitHub Actions e o GitLab CI são event-driven: disparam o pipeline automaticamente no push, sem necessidade de um servidor dedicado fazendo polling. Além disso, a alternativa não menciona a execução de testes nem o deploy, apenas o build.

Alternativa B — ❌ Incorreta

Configurar um ambiente de homologação permanente com atualização manual da aplicação é o oposto da automação desejada. O enunciado pede que, a cada push, sejam executados automaticamente build, testes e deploy. A atualização manual não atende a esse requisito e não é uma prática de CI/CD — é um processo manual sujeito a erros e atrasos.

Alternativa C — ❌ Incorreta

Configurar um script local de build e testes executado manualmente pelo desenvolvedor antes de cada commit também é o oposto da automação. A CI/CD existe justamente para eliminar a dependência de ações manuais, garantindo que o build e os testes sejam executados de forma consistente e automática a cada integração. Além disso, a alternativa não prevê a publicação da imagem nem o deploy.

Alternativa D — ✅ Correta ⟵ GABARITO

Definir um arquivo de pipeline declarativo no repositório, como .github/workflows/ci.yml ou .gitlab-ci.yml, descrevendo jobs automatizados, é exatamente a prática de CI/CD. Esses arquivos são versionados junto com o código, o que garante que a configuração do pipeline seja revisável, versionável e consistente. O GitHub Actions e o GitLab CI leem esses arquivos e executam os jobs automaticamente a cada push na branch main, realizando o build da imagem Docker, a execução dos testes e o deploy em homologação. Essa é a abordagem tecnicamente adequada e amplamente adotada.

Alternativa E — ❌ Incorreta

Habilitar webhooks no repositório para notificar desenvolvedores sobre novos commits, delegando a execução de build e testes a cada membro da equipe, não automatiza o processo. Webhooks apenas enviam notificações; a execução de build e testes ficaria a cargo de cada desenvolvedor, o que é manual, inconsistente e não é CI/CD. A automação deve ser centralizada na ferramenta de CI/CD, não delegada a membros da equipe.

Gabarito: letra D