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

GitLab CI/CD – Pipelines Parent-Child e Multi-Project

Gabarito: letra A. O job microservico_A dispara um único pipeline do tipo parent-child, pois a configuração usa apenas a palavra-chave trigger com include contendo um arquivo remoto (remote) e um arquivo de outro projeto (project), ambos dentro do mesmo bloco trigger. Isso cria um pipeline filho a partir do pipeline pai, e não pipelines multi-project, que exigiriam a sintaxe trigger: project: ... sem include.

O GitLab CI/CD oferece duas formas principais de orquestrar pipelines entre projetos: parent-child pipelines e multi-project pipelines. A diferença fundamental está na relação entre os pipelines e na sintaxe utilizada.

Parent-child pipelines são usados quando um pipeline (o pai) dispara um ou mais pipelines filhos, que são executados no mesmo projeto. O pipeline filho pode ser definido em um arquivo separado (via include) ou no próprio .gitlab-ci.yml. A sintaxe típica é:

microservico_A:
  trigger:
    include:
      - local: 'path/to/child.yml'
      - remote: 'https://example.com/child.yml'
      - project: 'group/project'
        ref: 'main'
        file: 'child.yml'

Quando você usa trigger com include, o GitLab cria um pipeline filho que herda o contexto do pipeline pai, mas é executado como um pipeline separado dentro do mesmo projeto. Isso é útil para dividir um pipeline grande em partes menores e mais gerenciáveis.

Multi-project pipelines, por outro lado, são usados para disparar pipelines em outros projetos. A sintaxe é:

staging:
  trigger:
    project: 'group/project'
    branch: 'main'

Nesse caso, o pipeline atual dispara um pipeline em outro projeto, e a relação é entre projetos diferentes. Não há include envolvido.

Na questão, o job microservico_A usa trigger com include contendo duas fontes: um arquivo remoto (remote) e um arquivo de outro projeto (project). Ambos são incluídos no pipeline filho, que é criado no mesmo projeto (o projeto A). Portanto, apenas um pipeline parent-child é criado. A inclusão de um arquivo de outro projeto via project não cria um pipeline multi-project; ela apenas importa a definição do pipeline filho de outro repositório, mas o pipeline resultante ainda é um filho do pipeline atual.

Alternativa A — ✅ Correta ⟵ GABARITO

A alternativa A está correta porque a configuração apresentada cria exatamente um pipeline parent-child. O job microservico_A usa trigger com include, que é a sintaxe para criar um pipeline filho. As duas fontes (remote e project) são apenas formas de obter o conteúdo do pipeline filho, mas o resultado é um único pipeline filho no mesmo projeto.

Alternativa B — ❌ Incorreta

A alternativa B está incorreta porque afirma que será criado um pipeline multi-project. Um pipeline multi-project é criado quando se usa trigger com project sem include. Neste caso, como há include, o pipeline é parent-child, não multi-project.

Alternativa C — ❌ Incorreta

A alternativa C está incorreta porque afirma que serão criados dois pipelines parent-child. A configuração tem apenas um bloco trigger, que cria um único pipeline filho. As duas fontes dentro do include são combinadas em um único pipeline filho, não em dois.

Alternativa D — ❌ Incorreta

A alternativa D está incorreta porque afirma que serão criados dois pipelines multi-project. Como explicado, a configuração não cria pipelines multi-project, e mesmo que criasse, seria apenas um, não dois.

Alternativa E — ❌ Incorreta

A alternativa E está incorreta porque afirma que serão criados dois pipelines, um parent-child e um multi-project. A configuração cria apenas um pipeline parent-child. Não há criação de pipeline multi-project.

Gabarito: letra A