Questão de Engenharia de Software — Geral — INSTITUTO AOCP 2026

GitLab CI/CD: pipelines, stages e regras de execução por branch

Gabarito: letra A. A alternativa A descreve corretamente a estrutura de um pipeline no GitLab CI: três stages sequenciais (test, build, deploy), com o job de test sem restrição de branch, o job de build restrito à branch main e o job de deploy também restrito à main e dependente do stage de build. Essa configuração atende aos três requisitos do enunciado na ordem especificada, usando os recursos nativos do GitLab CI (stages, rules e dependências entre stages).

O GitLab CI é uma ferramenta de integração contínua e entrega contínua (CI/CD) que permite automatizar o ciclo de vida do software, desde a execução de testes até a implantação em ambientes de produção. O coração dessa automação é o arquivo .gitlab-ci.yml, que define os jobs (tarefas) e os stages (estágios) do pipeline. Um pipeline é uma coleção de jobs organizados em stages, que são executados em ordem sequencial: um stage só inicia quando o anterior termina com sucesso. Dentro de um mesmo stage, os jobs podem rodar em paralelo.

A principal vantagem de usar stages é o controle de fluxo: se um job de um stage falha, os stages seguintes não são executados. Isso é essencial para o requisito (3) do enunciado — a implantação em homologação só deve ocorrer após um build bem-sucedido. Além disso, o GitLab CI oferece a diretiva rules, que permite controlar quando um job deve ser executado, com base em condições como o nome da branch, a presença de tags, alterações em arquivos específicos, entre outras. É essa diretiva que permite atender aos requisitos (1) e (2): o job de test roda em qualquer branch, enquanto o job de build só roda na main.

Na prática, a configuração da alternativa A funcionaria assim: o job test é definido sem rules (ou com uma regra que aceita todas as branches), o job build tem uma regra como rules: - if: '$CI_COMMIT_BRANCH == "main"', e o job deploy tem a mesma regra de branch e, por estar em um stage posterior, depende implicitamente do sucesso do build. Essa é a abordagem idiomática e recomendada pela documentação do GitLab.

A pegadinha desta questão está em distinguir a abordagem correta (usar stages e rules) das abordagens incorretas que tentam resolver o problema com scripts manuais, webhooks ou lógica invertida. A banca explora a confusão entre o que é responsabilidade do GitLab CI (execução condicional por branch) e o que seria uma gambiarra (verificar branch dentro de scripts Shell). Guarde o critério: no GitLab CI, a execução condicional por branch é feita com a diretiva rules (ou only/except), não com scripts dentro dos jobs — é exatamente nesse ponto que as alternativas se dividem.

Alternativa A — ✅ Correta ⟵ GABARITO

A alternativa A descreve a estrutura correta e idiomática do GitLab CI. Ela define três stages sequenciais (test, build, deploy), o que garante a ordem de execução e a dependência implícita entre eles: o deploy só roda se o build for bem-sucedido, atendendo ao requisito (3). O job de test é configurado sem restrição de branch, atendendo ao requisito (1) — testes em qualquer push. O job de build é restrito à branch main com rules, atendendo ao requisito (2). O job de deploy também é restrito à main, evitando implantações acidentais em branches de desenvolvimento. Essa é exatamente a configuração que a documentação do GitLab recomenda para esse cenário.

Alternativa B — ❌ Incorreta

A alternativa B propõe um stage único com três jobs paralelos. Isso viola o requisito (3), pois não há garantia de que o deploy ocorra após o build bem-sucedido — em paralelo, o deploy poderia rodar antes ou simultaneamente ao build. Além disso, configurar os três jobs para qualquer branch e usar variáveis de ambiente para decidir o comportamento é uma abordagem frágil e não idiomática: o GitLab CI já oferece a diretiva rules para controle condicional por branch, tornando desnecessário (e pior) o uso de scripts para essa finalidade. A ordem sequencial exigida pelo enunciado não é atendida.

Alternativa C — ❌ Incorreta

A alternativa C também coloca os três jobs em um único stage sequencial, o que até garantiria a ordem, mas configura os três jobs para executar em qualquer branch e usa scripts Shell dentro de cada job para verificar o nome da branch. Essa abordagem é considerada uma má prática no GitLab CI: a verificação de branch deve ser feita com a diretiva rules (ou only/except), não com scripts manuais. Além disso, mesmo que os scripts funcionassem, a configuração ficaria mais complexa e menos legível do que a solução nativa. A alternativa A é superior e correta; a C, embora pudesse funcionar na prática, não é a estrutura adequada e não atende ao requisito de forma idiomática.

Alternativa D — ❌ Incorreta

A alternativa D afirma que o GitLab CI não suporta execução condicional por branch em pipelines nativos, o que é falso. O GitLab CI tem suporte nativo a rules, only e except, que permitem condicionar a execução de jobs ao nome da branch. Portanto, não há necessidade de usar webhooks externos para os testes. A premissa da alternativa é incorreta, e a solução proposta (webhooks externos) é desnecessária e mais complexa do que a configuração nativa.

Alternativa E — ❌ Incorreta

A alternativa E inverte a ordem lógica do pipeline: coloca o job de test com dependência do resultado do deploy. Isso é um contrassenso, pois os testes devem ser executados antes da implantação, para validar o código antes de colocá-lo em produção ou homologação. A ordem correta é test → build → deploy, como na alternativa A. Além disso, a justificativa apresentada (testar o ambiente de homologação antes de disponibilizar a versão) não faz sentido no contexto de CI/CD, onde os testes são executados no código-fonte, não no ambiente de homologação.

Gabarito: letra A