github¶

a integração com github permite publicar um pipeline de desenvolvimento para produção através de um pull request — trazendo revisão de código e rastreabilidade de mudanças para o mundo dos pipelines visuais, do mesmo jeito que já acontece com código-fonte tradicional.

por que isso importa

sem essa integração, promover um pipeline de "em desenvolvimento" para "produção" é uma ação direta, sem revisão nem histórico versionado fora da própria plataforma. conectando ao github, cada promoção vira um pull request revisável, com o time podendo comentar, aprovar ou pedir ajustes antes do merge — o mesmo rigor que já existe para mudanças de código, aplicado a pipelines de dados.

conectando a organização ao github¶

a conexão é feita uma vez por organização, através de um GitHub App instalado na conta ou organização do github do cliente. depois de instalado:

a organização fica associada à instalação do GitHub App.
é possível definir um repositório padrão para a organização, embora cada pipeline também possa apontar para um repositório diferente.

essa conexão pode ser removida a qualquer momento, desativando a integração para toda a organização.

configurando o repositório de um pipeline¶

cada pipeline do tipo "desenvolvimento" pode ser associado a um repositório específico do github, definindo:

o repositório (owner/repo);
a branch base para onde os pull requests serão abertos (por padrão, main);
o caminho dentro do repositório onde os arquivos do pipeline serão versionados (por padrão, pipelines).

publicando um pipeline (deploy)¶

ao publicar um pipeline de desenvolvimento, a datablixt:

exporta o pipeline (workflows, nós e configuração) para um pacote json;
cria uma branch específica para o deploy, a partir da branch base configurada;
faz commit do pacote json nessa branch;
abre um pull request da branch de deploy para a branch base, com uma descrição automática listando os workflows incluídos;
registra o deployment na datablixt com status "pendente".

apenas pipelines de desenvolvimento podem ser publicados

a publicação via github é exclusiva de pipelines com branch developer — pipelines de produção não passam novamente por esse fluxo de publicação.

o que acontece quando o pull request é aprovado (merge)¶

quando o pull request é mergeado no github, a plataforma recebe automaticamente essa notificação (veja webhooks) e:

importa o pacote json versionado na branch, criando (ou atualizando) o pipeline correspondente em produção;
marca o deployment como "implantado" (deployed).

se o pull request for fechado sem merge, o deployment é marcado como "cancelado" — nenhuma mudança é aplicada em produção.

se a importação falhar por qualquer motivo (por exemplo, um erro no pacote exportado), o deployment é marcado como "falhou", com o detalhe do erro registrado para investigação.

trilha de auditoria¶

a conexão da organização ao github, a configuração de repositório por pipeline e cada publicação (deploy) ficam registradas na trilha de auditoria da plataforma.