06 · RELEASE MANAGER

Você aprova exatamente a mudança que vai para produção.

O Heimdall não faz deploy: ele commita no seu repositório de manifestos, e o Argo CD que você já tem aplica. Ficam registrados quem pediu, quem aprovou, quando o deploy era permitido e o commit exato.

Falar com engenharia

Abre uma conversa no WhatsApp. Prefere e-mail? heimdall@yops.cloud

O que faz

De onde vêm as versões

Uma release publicada no repositório de código vira uma versão do Component, por webhook ou por consulta periódica. A imagem é montada e congelada no momento em que a release é registrada.

Onde cada versão é escrita

Para cada Component e environment, um alvo indica o arquivo, o documento YAML e o caminho do valor. Itens de lista são escolhidos pelo nome, nunca pela posição; por isso, um sidecar acrescentado no topo não desloca a versão para o container errado. Além do valor trocado, nada muda no arquivo.

O que se aprova é o diff

Os aprovadores veem a mudança, de uma linha, e a decisão fica vinculada à impressão digital dela. No deploy, o Agente relê o arquivo e a API refaz a mudança; se a impressão digital não bater, o commit é recusado, e a recusa diz o que mudou.

Quem aprova e por quanto tempo

Cada environment tem pessoas ou grupos nomeados e um quórum. "Staging não pede aprovação, produção pede" se resolve na configuração. A decisão tem prazo para ser tomada e prazo para valer — 4 horas por padrão. Ninguém aprova o próprio pedido.

O portão, consultado duas vezes

O portão confere a janela de deploy (num fuso IANA), o congelamento (com motivo obrigatório) e a imagem no registry, e dá a resposta de cada condição, inclusive das que permitem o deploy. Ele é consultado no início do deploy e de novo no instante anterior ao commit; se a janela fechar no meio do caminho, o commit não acontece.

O rollback, sem escolha de destino

Um comando, acompanhado de motivo, restaura a versão que aquele Component tinha naquele environment antes do último deploy — sempre uma versão que já passou por aprovação. Ele não espera aprovação nem janela, atravessa o congelamento, avisa os aprovadores e abre um incidente. Desfaz um único passo.

O que o Heimdall nunca afirma

Não existe o estado "em produção": committed quer dizer só que o commit existe. Para saber o que o Argo CD fez com ele, heimdall release drift pergunta ao próprio Argo CD — e se recusa a responder sobre uma Application que não observa o arquivo escrito pelo Heimdall.

Como funciona

Um deploy, da aprovação ao commit:

A API consulta o portão.
O Agente lê o manifesto no seu repositório.
A mudança é refeita sobre o arquivo lido e comparada com a que foi aprovada. Se o arquivo mudou nesse meio-tempo, ele é recusado.
A API consulta o portão de novo, porque a janela pode ter fechado enquanto o Agente lia o arquivo.
O Agente faz o commit condicionado à versão do arquivo que leu. O seu Argo CD aplica no ritmo dele.

TERMINALheimdall release plan

$ heimdall release plan 2a5e9fa9-e606-4306-883e-842f4082901d --env 99f09f2c-e1ed-8cea-8a5d-4e3fe36507fc --release 394f1285-e26f-4f00-ab60-d50e7e5a0d09 --manifest ./deployment.yaml
✓ Deploying 6.7.0 would change one line of apps/checkout/deployment.yaml

Release:     6.7.0 (394f1285-e26f-4f00-ab60-d50e7e5a0d09)
Branch:      (the connection's default branch)
Value path:  spec.template.spec.containers[name=checkout-api].image (image_reference, document 0)
Line 22:      ghcr.io/stefanprodan/podinfo:6.6.0 -> ghcr.io/stefanprodan/podinfo:6.7.0
Blob:        dced867f50e738f55f2bd19fc54a8d1fce203765
Fingerprint: c7056bc6c5d849686a8c79e2433bfe70a54656ffe6f5aca369298cd8d9781417

--- a/apps/checkout/deployment.yaml
+++ b/apps/checkout/deployment.yaml
@@ -19,7 +19,7 @@
         - name: istio-proxy
           image: docker.io/istio/proxyv2:1.23.0
         - name: checkout-api
-          image: ghcr.io/stefanprodan/podinfo:6.6.0   # versão atual
+          image: ghcr.io/stefanprodan/podinfo:6.7.0   # versão atual
           ports:
             - containerPort: 9898
           readinessProbe:

Saída real de heimdall release plan: a mudança que o aprovador vai ver.

Onde o dado fica

Tudo roda na sua infraestrutura. Mesmo assim, a divisão abaixo importa dentro da sua empresa, porque mostra quem, no seu time, tem acesso a quê.

Release Manager: onde o dado fica
NO AGENTE	NA API, QUE É SUA
A leitura do repositório de manifestos e o commit nele, com um token que vale cerca de uma hora, restrito a um único repositório e nunca gravado. O endereço, o certificado e o token do seu Argo CD.	Fontes, alvos, aprovadores, janelas e congelamentos. Cada pedido, cada voto e a impressão digital do que foi aprovado. O histórico de deploys e de rollbacks. O manifesto lido passa pela API, que refaz a mudança.

Ver a segurança

Quem aprova o quê

Release Manager: quem aprova o quê
ATO	QUEM
Ver releases e perguntar ao portão	todo membro
Configurar fonte, alvo, aprovadores e janela; pedir deploy; fazer deploy e rollback	`owner` e `admin`, por padrão. Uma `policy` estende a permissão a quem o seu time decidir
Aprovar	os aprovadores nomeados do Component naquele `environment` — nunca quem pediu
Dispensar a janela de um pedido	um aprovador nomeado, com motivo — nunca quem pediu. O congelamento e a imagem continuam valendo
Declarar e encerrar um congelamento; mudar o prazo da aprovação	`owner`

Com os outros módulos

01

Catálogo

Alvo, aprovadores, janela e congelamento são definidos por Component e por environment.
07

Incident Manager

Todo rollback abre um incidente datado do momento em que a versão desfeita chegou: o tempo de reparo começa a contar quando o problema entrou, e não quando alguém reagiu.
03

Secret Manager

O token do Argo CD é um secret no Agente.

Converse com quem constrói o Heimdall.

Conte como a sua engenharia guarda secrets e acessa o banco hoje. Respondemos dizendo o que o Heimdall colocaria sob regra primeiro e como a implantação chegaria lá.