Publicar uma pipeline

Desenhar a pipeline não coloca nada no ar. Quem faz isso é o deploy — e ele tem mais etapas do que um botão de "salvar".

O que acontece quando você publica

1. A plataforma gera os arquivos de configuração a partir do seu desenho.
2. Esses arquivos são comitados numa branch do Git, com a mensagem que você escrever.
3. O ArgoCD percebe o commit e aplica tudo no cluster escolhido.
4. Cada peça da pipeline sobe como uma carga de trabalho independente.

Duas consequências práticas desse modelo:

• Todo deploy fica registrado no Git. Dá para ver quem publicou o quê, quando, e voltar atrás.
• Publicar não é instantâneo. O commit é imediato; a aplicação no cluster leva alguns instantes até o ArgoCD sincronizar.

A tela de Deploy

Abra a pipeline e vá em Deploy. São três abas:

Aba	Para que serve
Deploys	Lista o que já está no ar, em qual cluster e com que saúde
Novo Deploy	Onde o deploy é feito
Variáveis	Configuração que muda de cluster para cluster

A ordem importa

Configure a aba Variáveis antes do primeiro deploy. As variáveis valem a partir do próximo deploy naquele cluster — criar depois não conserta um deploy que já subiu sem elas.

Passo 1 — Variáveis

Esta aba existe porque a mesma pipeline roda em clusters diferentes com valores diferentes: o banco de homologação não é o de produção, e a senha não é a mesma.

Tudo aqui é por cluster. O seletor no topo escolhe qual, e o aviso ao lado é literal: alterações têm efeito no próximo deploy para este cluster.

De onde vêm as variáveis

Você não inventa os nomes. No editor da pipeline, quase todo campo de configuração tem um botão ${…} ao lado. Clicar nele troca o valor fixo por uma referência de variável, e a plataforma gera o nome automaticamente no formato N{número-do-node}_{CAMPO}:

Campo no node 2	Vira a variável
Host do SFTP	N2_SFTP_HOST
Host do SQL Server	N2_SQLSERVER_HOST
Senha do PostgreSQL	N2_POSTGRES_PASSWORD

O nome é editável, mas só aceita letras, números e underline — e é sempre gravado em maiúsculas.

Depois de marcar o campo como variável no desenho, é aqui na aba Variáveis que você diz qual o valor dela em cada cluster.

Conexões Kafka por cluster

O primeiro bloco da aba. Ele permite apontar a pipeline para clusters Kafka diferentes conforme o ambiente, sem mexer no desenho.

Linha	O que controla	Chave
Pipeline (nós intermediários)	O Kafka usado pelos nodes de Transform	INTHUB_KAFKA_CONNECTION
Nó N (source kafka) / Nó N (sink kafka)	O Kafka de um Input ou Output Kafka específico	INTHUB_KAFKA_CONNECTION_N{n}

Aparece uma linha por node Kafka que a pipeline tiver. Deixar como "Não configurada" faz a peça usar a conexão padrão escolhida no próprio desenho — o que é o certo na maioria dos casos.

As conexões disponíveis na lista são as cadastradas em Kafka → Conexões.

Variáveis de ambiente

O segundo bloco. Cada variável tem uma Chave e um valor, e o valor pode vir de dois lugares:

Modo	Quando usar	O que você preenche
Valor plain	Dados não sensíveis: host, porta, nome de banco, caminho	O valor direto
Secret	Senhas, tokens, chaves	O Secret cadastrado + a Chave do secret

A Chave do secret é o nome do campo dentro do secret — por exemplo password, ou credentials.json para uma credencial de service account. Um secret pode guardar mais de um campo, e é essa chave que diz qual deles você quer.

Secrets restritos a um cluster

Um secret cadastrado com destino a um cluster específico só aparece na lista quando aquele cluster está selecionado. Se um secret que você espera ver não está na lista, confira o destino dele em Workspace → Secrets.

Uma variável listada em vermelho como "não configurado" está criada mas sem valor — a peça vai subir sem aquele dado.

Passo 2 — Novo Deploy

Com as variáveis prontas, vá para a aba Novo Deploy.

Cluster destino

Onde a pipeline vai rodar. Precisa ser o mesmo cluster para o qual você configurou as variáveis.

Versão para deploy

Opção	O que faz
Alterações atuais	Publica o desenho como ele está agora e cria uma versão nova (o chip mostra qual: cria v3)
v1, v2, …	Publica uma versão anterior, exatamente como ela era

Publicar uma versão anterior é o mecanismo de rollback: se um deploy deu problema, escolha a versão que funcionava e publique de novo.

Ao lado do seletor há um botão <> que mostra o YAML gerado antes de publicar. Vale abrir na primeira vez: é ali que dá para conferir se as variáveis foram resolvidas como você esperava.

Branch

Onde o commit será feito.

• Branch existente — escolha uma da lista.
• Nova branch — informe o nome, ex.: feature/minha-branch.

Publicar numa branch separada é o caminho quando a mudança precisa de revisão antes de chegar ao ambiente principal.

Mensagem do commit

Obrigatória. Vem preenchida com um texto padrão (deploy a pipe <nome>, version <n>), mas vale trocar por algo que explique o que mudou — é o que outra pessoa vai ler no histórico daqui a seis meses.

Tags

Obrigatórias. São os rótulos que organizam as pipelines: é por elas que se filtra a lista, se descobre tudo o que pertence a um time ou a um sistema, e se encontra o que precisa mudar quando um sistema de origem sai do ar.

Uma pipeline sem tag some no meio das outras assim que a plataforma passa de algumas dezenas — por isso a marcação é cobrada no deploy, e não deixada para depois.

Use rótulos que respondam "de quem é isto" e "o que isto integra": financeiro, erp, producao, replicacao. Vale reaproveitar tags já existentes — a lista sugere as que a empresa já usa.

Confirmação

Antes do botão, a tela mostra o nome do deploy que será criado e quem é o autor:

minha-pipeline-deploy-3-producao

O padrão é {pipeline}-deploy-{versão}-{cluster}.

O botão Deploy só habilita quando cluster, branch e mensagem de commit estão preenchidos.

Passo 3 — Acompanhe

Depois de publicar, a tela volta para a aba Deploys, que lista cada deploy ativo:

Coluna	O que mostra
Cluster	Onde está rodando, e o nome do deploy
Versão	Qual versão do desenho está no ar
Status	Saúde e sincronização reportadas pelo ArgoCD
Data	Quando foi aplicado
Ações	Abrir a observabilidade, ou remover o deploy

O status é o que dizer se deu certo. Enquanto o ArgoCD estiver sincronizando, ele muda sozinho — espere estabilizar antes de concluir que algo falhou. Se ficar em estado de falha, abra a observabilidade para ver o log da peça que não subiu.

Remover um deploy

O botão de lixeira na aba Deploys tira a pipeline daquele cluster. As peças param, mas os tópicos e as mensagens acumuladas continuam existindo — publicar de novo faz cada peça retomar de onde parou.

Publicar em mais de um cluster

A mesma pipeline pode estar no ar em vários clusters ao mesmo tempo, cada um com seus próprios valores. O ciclo é o mesmo, repetido por cluster:

1. Aba Variáveis → selecione o cluster → configure os valores dele.
2. Aba Novo Deploy → selecione o mesmo cluster → publique.

Esquecer o passo 1 para o segundo cluster é o erro mais comum: a pipeline sobe apontando para os valores errados, ou sem valor nenhum.

Erros comuns

Sintoma	Causa provável
O botão Deploy não habilita	Falta cluster, branch ou mensagem de commit
A peça sobe e cai em seguida	Variável sem valor, ou secret com a Chave do secret errada
A pipeline aponta para o ambiente errado	Variáveis configuradas em outro cluster que não o do deploy
A publicação é recusada na validação	Um Output sem ligação, campo obrigatório vazio, ou secret removido — veja Pipelines
O deploy foi feito mas nada mudou no cluster	O ArgoCD ainda não sincronizou; confira a coluna Status

Checklist

Antes de publicar pela primeira vez em um cluster:

• O desenho está completo e cada Transform e Output está ligado a algum tópico.
• Os campos que mudam por ambiente estão marcados como variável (${…}) no editor.
• Os Secrets já estão cadastrados.
• A aba Variáveis está preenchida para o cluster de destino.
• O YAML gerado foi conferido no botão <>.
• A mensagem do commit diz o que mudou.
• As tags estão preenchidas.