Skip to main content
MKA1 follows a GitOps-aligned deployment model where the Git repository is the single source of truth for all infrastructure and application state. Every deployment is an atomic Helm transaction: if any resource fails to become healthy, the entire release rolls back automatically with no manual intervention.

​
What is active

​
Git as the single source of truth

The entire MKA1 platform is defined as a single Helm chart (mka1-platform) stored in the infra-resources Git repository. No change reaches a cluster without first being committed and reviewed via pull request.
  • Helm chart and values files define every workload, service, secret template, HPA, and PDB for the platform.
  • Environment-specific overrides separate staging and production configuration while sharing the same chart definition.
  • Encrypted secrets are managed with SOPS and committed alongside the chart, ensuring that even sensitive configuration is tracked in Git history.

​
Atomic Helm deploys

Helm releases are executed with the --atomic flag, which wraps the entire upgrade in a transaction. If any resource in the release fails its readiness check, Helm automatically rolls the entire release back to the previous known-good revision. 
helm upgrade --install mka1 mka1-platform \
  --atomic \
  --wait \
  --timeout 15m \
  -f values.yaml
  • --atomic — If the upgrade fails at any point, Helm deletes the new resources and restores the previous release. The cluster never stays in a partially deployed state.
  • --wait — Helm waits for all Pods, Services, and other resources to report ready before marking the release as successful.
  • --timeout 15m — A configurable ceiling prevents deployments from hanging indefinitely. If readiness is not achieved within the window, the release is treated as failed and rolled back.

​
Automated reconciliation via CI/CD

GitHub Actions workflows trigger automatically on every push to main that modifies infrastructure paths. The pipeline authenticates with AWS, configures kubectl for the target EKS cluster, and applies the Git-defined desired state:
  1. A developer merges a pull request into main.
  2. GitHub Actions detects the change and triggers the deployment workflow.
  3. The workflow checks out the repository at the merged commit SHA.
  4. helm upgrade --install --atomic reconciles the cluster to match the desired state defined in Git.
  5. If the desired state cannot be reached, the atomic rollback guarantees the cluster remains on the last successful revision.

​
Immutable deployment history

Every Helm release creates a versioned revision stored in the cluster. This provides a complete audit trail of what was deployed, when, and from which Git commit. 
helm history mka1-platform
helm rollback mka1-platform <revision>
Combined with Git commit history, this gives full traceability from code change to deployed state.

​
How we validate it

We validate the GitOps workflow by inspecting the deployed Helm release state and confirming it matches the Git-defined configuration. 
helm list
kubectl rollout status deployment/<name>
helm get values mka1-platform
The CI/CD pipeline itself serves as continuous validation: every push to main triggers a full reconciliation cycle. If the cluster state drifts from the Git-defined desired state, the next pipeline run corrects it.

​
Evidence

​
Helm atomic upgrade flow

The following demonstrates the atomic deploy behavior. When all resources become healthy, the release succeeds: 
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
When a resource fails its readiness check, the entire release is automatically rolled back: 
Error: UPGRADE FAILED: release mka1-platform failed, and has been rolled back
  due to atomic being set: timed out waiting for the condition
No partial state is left behind — the cluster remains on the previous healthy revision.

​
Helm release history

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
Each revision is a point-in-time snapshot of the deployed configuration, enabling instant rollback to any previous state.