O Que É um Parent-Child Pipeline? Dividindo um Pipeline Grande
Um parent-child pipeline quebra um pipeline grande em um parent que dispara um ou mais pipelines child, geralmente um por componente ou área.
Um único arquivo de pipeline descrevendo tudo o que um repositório grande faz torna-se ilegível e lento de manter. O padrão parent-child o divide: um pequeno pipeline parent decide o que mudou e dispara pipelines child focados para os componentes afetados. Cada child é mais simples, e componentes não afetados não executam.
Como a divisão funciona
O pipeline parent executa primeiro e atua como um dispatcher. Ele pode inspecionar o que mudou e disparar dinamicamente apenas os pipelines child relevantes, cada um sendo um pipeline autocontido para uma parte da base de código.
Por que dividir assim
- Config menor e legível por componente.
- Executar apenas os children afetados por uma mudança.
- Times donos do seu pipeline child de forma independente.
Um exemplo rápido
Em um monorepo com frontend/, backend/ e infra/, o parent detecta quais pastas mudaram e dispara apenas esses pipelines child. Uma mudança apenas em docs pula inteiramente os children de backend e infra.
Parent-child vs downstream
Pipelines parent-child geralmente vivem no mesmo projeto e são divididos para organização. Um downstream pipeline frequentemente cruza para outro projeto. A mecânica se sobrepõe, mas a intenção difere: estrutura versus encadeamento entre projetos.
Benefícios de custo
Como children não afetados não executam, esse padrão corta computação desperdiçada em repositórios grandes. Combinado com runners medidos (Latchkey), você pode ver quanto cada pipeline child custa e podar aqueles que raramente capturam algo.
Principais conclusões
- Um parent-child pipeline divide um pipeline grande em um dispatcher mais children.
- O parent dispara apenas os pipelines child afetados por uma mudança.
- Ele mantém a config legível e evita executar componentes não relacionados.