Saltar para o conteúdo principal
A MKA1 segue um modelo de deploy alinhado ao GitOps, onde o repositório Git é a fonte única de verdade para todo o estado de infraestrutura e aplicação. Cada deploy é uma transação atômica do Helm: se qualquer recurso falhar em se tornar saudável, toda a release é revertida automaticamente sem intervenção manual.

​
O que está ativo

​
Git como fonte única de verdade

Toda a plataforma MKA1 é definida como um único Helm chart (mka1-platform) armazenado no repositório Git infra-resources. Nenhuma alteração chega a um cluster sem antes ser commitada e revisada via pull request.
  • Helm chart e arquivos de valores definem cada workload, service, template de secret, HPA e PDB da plataforma.
  • Overrides por ambiente separam a configuração de staging e produção, compartilhando a mesma definição de chart.
  • Secrets criptografados são gerenciados com SOPS e commitados junto ao chart, garantindo que até a configuração sensível seja rastreada no histórico do Git.

​
Deploys atômicos com Helm

As releases do Helm são executadas com a flag --atomic, que envolve toda a atualização em uma transação. Se qualquer recurso na release falhar na verificação de readiness, o Helm automaticamente reverte toda a release para a revisão anterior conhecida como saudável. 
helm upgrade --install mka1 mka1-platform \
  --atomic \
  --wait \
  --timeout 15m \
  -f values.yaml
  • --atomic — Se o upgrade falhar em qualquer ponto, o Helm exclui os novos recursos e restaura a release anterior. O cluster nunca permanece em um estado parcialmente implantado.
  • --wait — O Helm aguarda que todos os Pods, Services e outros recursos reportem estar prontos antes de marcar a release como bem-sucedida.
  • --timeout 15m — Um limite configurável impede que deploys fiquem pendurados indefinidamente. Se o readiness não for atingido dentro da janela, a release é tratada como falha e revertida.

​
Reconciliação automatizada via CI/CD

Workflows do GitHub Actions são disparados automaticamente a cada push para main que modifica caminhos de infraestrutura. O pipeline se autentica na AWS, configura o kubectl para o cluster EKS de destino e aplica o estado desejado definido no Git:
  1. Um desenvolvedor faz merge de um pull request na main.
  2. O GitHub Actions detecta a alteração e dispara o workflow de deploy.
  3. O workflow faz checkout do repositório no SHA do commit mergeado.
  4. helm upgrade --install --atomic reconcilia o cluster para corresponder ao estado desejado definido no Git.
  5. Se o estado desejado não puder ser alcançado, o rollback atômico garante que o cluster permaneça na última revisão bem-sucedida.

​
Histórico imutável de deploys

Cada release do Helm cria uma revisão versionada armazenada no cluster. Isso fornece uma trilha de auditoria completa do que foi implantado, quando e a partir de qual commit do Git. 
helm history mka1-platform
helm rollback mka1-platform <revision>
Combinado com o histórico de commits do Git, isso oferece rastreabilidade completa da alteração de código até o estado implantado.

​
Como validamos isso

Validamos o workflow GitOps inspecionando o estado da release Helm implantada e confirmando que ele corresponde à configuração definida no Git. 
helm list
kubectl rollout status deployment/<name>
helm get values mka1-platform
O próprio pipeline de CI/CD serve como validação contínua: cada push para main dispara um ciclo completo de reconciliação. Se o estado do cluster divergir do estado desejado definido no Git, a próxima execução do pipeline o corrige.

​
Evidências

​
Fluxo de upgrade atômico do Helm

O trecho a seguir demonstra o comportamento do deploy atômico. Quando todos os recursos se tornam saudáveis, a release tem sucesso: 
Release "mka1-platform" has been upgraded. Happy Helming!
NAME: mka1-platform
LAST DEPLOYED: 2026-04-01 18:32:05
NAMESPACE: default
STATUS: deployed
REVISION: 42
Quando um recurso falha na verificação de readiness, toda a release é automaticamente revertida: 
Error: UPGRADE FAILED: release mka1-platform failed, and has been rolled back
  due to atomic being set: timed out waiting for the condition
Nenhum estado parcial é deixado para trás — o cluster permanece na revisão saudável anterior.

​
Histórico de releases do Helm

REVISION  UPDATED                   STATUS      DESCRIPTION
40        2026-03-28 14:10:22       superseded  Upgrade complete
41        2026-03-30 09:45:11       superseded  Upgrade complete
42        2026-04-01 18:32:05       deployed    Upgrade complete
Cada revisão é um snapshot pontual da configuração implantada, permitindo rollback instantâneo para qualquer estado anterior.