> ## Documentation Index > Fetch the complete documentation index at: https://docs.mka1.com/llms.txt > Use this file to discover all available pages before exploring further. # GitOps com rollback atômico > Como o MKA1 usa o Git como fonte única da verdade e Helm com deploys atômicos para garantir rollback automático em caso de falha. MKA1 segue um modelo de implantação alinhado ao GitOps, onde o repositório Git é a fonte única da verdade para toda a infraestrutura e estado das aplicações. Cada implantação é uma transação atômica do Helm: se algum recurso não se tornar saudável, todo o release é revertido automaticamente, sem intervenção manual. ## O que está ativo ### Git como fonte única da verdade Toda a plataforma MKA1 é definida como um único Helm chart (`mka1-platform`) armazenado no repositório Git `infra-resources`. Nenhuma alteração chega ao cluster sem antes ser commitada e revisada via pull request. * **Helm chart e arquivos de valores** definem todas as workloads, serviços, templates de segredos, HPA e PDB da plataforma. * **Overrides específicos por ambiente** separam as configurações de staging e produção, compartilhando a mesma definição de chart. * **Segredos criptografados** são gerenciados com SOPS e commitados junto com o chart, garantindo que até configurações sensíveis sejam rastreadas no histórico do Git. ### Deploys atômicos com Helm Os releases do Helm são executados com o parâmetro `--atomic`, que envolve toda a atualização em uma transação. Se algum recurso do release falhar na verificação de prontidão, o Helm reverte automaticamente todo o release para a última revisão conhecida como estável. ```bash theme={null} helm upgrade --install mka1 mka1-platform \ --atomic \ --wait \ --timeout 15m \ -f values.yaml ``` * **`--atomic`** -- Se a atualização falhar em qualquer ponto, o Helm deleta os novos recursos e restaura o release anterior. O cluster nunca fica em um estado parcialmente implantado. * **`--wait`** -- O Helm espera que todos os Pods, Serviços e outros recursos estejam prontos antes de marcar o release como bem-sucedido. * **`--timeout 15m`** -- Um limite configurável impede que os deploys fiquem travados indefinidamente. Se a prontidão não for atingida dentro do tempo, o release é considerado falho e revertido. ### Reconciliação automatizada via CI/CD Workflows do GitHub Actions são acionados automaticamente a cada push no `main` que modifica caminhos de infraestrutura. O pipeline autentica com a AWS, configura o `kubectl` para o cluster EKS alvo e aplica o estado desejado definido no Git: 1. Um desenvolvedor faz merge de um pull request no `main`. 2. O GitHub Actions detecta a alteração e aciona o workflow de implantação. 3. O workflow faz checkout do repositório no SHA do commit mesclado. 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 de deploys imutável Cada release do Helm cria uma revisão versionada armazenada no cluster. Isso fornece uma trilha completa de auditoria do que foi implantado, quando e a partir de qual commit do Git. ```bash theme={null} helm history mka1-platform helm rollback mka1-platform ``` Combinado com o histórico de commits do Git, isso oferece rastreabilidade total da alteração de código até o estado implantado. ## Como validamos Validamos o fluxo GitOps inspecionando o estado do release Helm implantado e confirmando que ele corresponde à configuração definida no Git. ```bash theme={null} helm list kubectl rollout status deployment/ helm get values mka1-platform ``` O próprio pipeline CI/CD serve como validação contínua: todo push no `main` aciona 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 corrige o desvio. ## Evidências ### Fluxo de upgrade atômico do Helm O exemplo a seguir demonstra o comportamento do deploy atômico. Quando todos os recursos ficam saudáveis, o release é bem-sucedido: ```text theme={null} 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 prontidão, todo o release é revertido automaticamente: ```text theme={null} 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 última revisão saudável. ### Histórico de releases do Helm ```text theme={null} 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 do momento da configuração implantada, permitindo rollback instantâneo para qualquer estado anterior.