GitOps for SAP's No-Code Platform
Running SAP AppGyver on Gardener Kubernetes the GitOps way: GitHub Actions builds and tests, ArgoCD reconciles Git into the cluster, and every change to production is a reviewed, auditable commit.
SAP AppGyver is SAP's low-code, no-code platform: business users assemble apps visually, but underneath sits a real distributed system that has to be built, secured and run like any other. This engagement took the same engineering discipline applied across the wider SAP estate, including the SAP RPA work, and put it behind a GitOps delivery model on Gardener Kubernetes clusters.
The difference from the rest of the estate was the delivery stack. Nothing reaches a Gardener cluster by hand. Git is the single source of truth for desired state, GitHub Actions proves each change in CI, and ArgoCD does the continuous delivery by reconciling that desired state onto the live clusters. The role: Lead DevOps Engineer at CloudXOps, owning the platform pipelines, the SAP service integrations, and the audit and standardisation discipline that keeps an SAP-scale estate compliant.
The brief: a no-code platform that still needs real DevOps
AppGyver is no-code for the people building apps on it. It is emphatically not no-ops for the people running it. The platform components ran on SAP Gardener clusters and integrated SAP-specific platform services: identity, the service broker, and the managed backing services that AppGyver apps depend on.
- Kubernetes on Gardener, SAP's own cluster-as-a-service, so platform deployment had to fit Gardener's shoot lifecycle and projects model rather than a generic cluster assumption.
- SAP platform service integration, wiring AppGyver into SAP identity, entitlements and managed services through declarative config that lives in Git, not in a console somebody clicked.
- One immutable artifact per change, built once in CI and promoted by changing the desired state, never rebuilt per environment.
- Auditability by default, every production change traceable to a commit, a reviewer and a pipeline run, which is what an SAP estate's compliance posture demands.
CI builds and tests, ArgoCD syncs
The flow splits cleanly into two halves that never blur together. GitHub Actions owns continuous integration: on every commit it builds the container image, runs the test suites, and pushes a scanned, signed artifact plus an updated manifest. ArgoCD owns continuous delivery: it watches the Git repository that holds the desired cluster state and reconciles any difference between Git and the live Gardener cluster.
Crucially, GitHub Actions never runs kubectl apply against production. It builds and it writes the new desired state to Git. ArgoCD is the only thing that talks to the cluster, and it only ever moves the cluster toward what Git already says. That separation is what makes the pipeline auditable: the deployment is a diff, and the diff is a reviewed commit.
- Push, a change lands in Git as a commit on the platform repo.
- Build (CI), GitHub Actions builds, tests, scans, and updates the desired-state manifest.
- Detect drift, ArgoCD sees the live cluster no longer matches Git and marks it OutOfSync.
- Reconcile (CD), ArgoCD applies the desired state and the cluster converges back to Synced.
Watch a GitOps reconcile happen
Press Push commit. A new commit chip drops into Git (desired), GitHub Actions runs a short build, then ArgoCD detects that the live Gardener cluster has drifted from Git and reconciles it: the cluster tiles flip from amber OutOfSync to green Synced one at a time while the drift count walks down to zero. Push again and another commit briefly drifts the cluster before ArgoCD re-syncs it.
Git is the desired state, the cluster is a cache of it. Once ArgoCD owns reconciliation, a hotfix typed straight into the cluster is not a fix, it is drift that ArgoCD will quietly undo on its next pass. The only durable way to change production is to change Git, which is exactly the property you want from an SAP-grade audit trail.
The supporting stack, same as the wider SAP estate
GitOps sat on top of the same standardised toolchain used across the SAP estate, so the platform looked and audited like its neighbours rather than a one-off.
- Terraform for infrastructure as code, so Gardener projects and surrounding cloud resources were versioned, reviewed and reproducible.
- GitHub Actions and Jenkins for CI, with GitHub as the source of truth and ArgoCD as the delivery engine.
- SonarQube, WhiteSource, BlackDuck and GHAS for code quality, open-source licence and vulnerability scanning, and GitHub Advanced Security, all wired into the pipeline gates.
- Audit, standardisation and mentorship, the same discipline as the SAP RPA work: consistent pipelines, traceable changes, and engineers brought up to run them.
Takeaways
- A no-code platform still needs full DevOps: AppGyver runs as a real distributed system on Gardener.
- Split the pipeline cleanly: GitHub Actions builds and tests, ArgoCD reconciles desired state from Git.
- Let nothing touch the cluster but ArgoCD, so every production change is a reviewed, auditable commit.
- Reuse the estate's standard stack, Terraform, the scanners and GHAS, so the platform audits like its peers.
Want GitOps your auditors trust?
We put GitHub Actions in front of CI and ArgoCD in front of delivery, so your Kubernetes estate, Gardener or otherwise, only ever reflects a reviewed commit.
Set up GitOps delivery