A Git commit can describe a deployment perfectly while the application still fails to serve users.
A database may exist without accepting connections. A required secret may be missing from older environments. A running frontend may communicate with the wrong backend.
These gaps explain why GitOps requires more engineering than the phrase “push to deploy” suggests.
GeekyAnts, Adobe, Intuit, Red Hat, and GitLab provide useful examples of different parts of this problem. This selection highlights documented implementations and tooling contributions, rather than ranking companies by deployment performance.
What can a real provisioning platform reveal?
GeekyAnts’ engineering account of the hidden complexity behind GitOps describes isolated customer environments provisioned through ApplicationSets, Helm, and Argo CD.
A recorded provisioning run reached Synced+Healthy in approximately 110 seconds. However, operational incidents exposed four gaps:
- Dependencies existed before they were usable.
- Configuration changes broke existing tenants.
- Healthy deployments concealed broken integrations.
- Resource allocations prevented work despite spare cluster capacity.
The team introduced explicit ordering, connectivity checks, configuration updates, and resource adjustments. The article distinguishes observed provisioning time from projected capacity, which was calculated rather than established through concurrent load testing.
Why does deployment ordering need additional checks?
Argo CD supports sync phases and numbered waves to sequence resources. Its documentation also describes PostSync hooks for checks after successful synchronization and healthy resource status.
These mechanisms provide places to express deployment dependencies and run smoke tests. Their usefulness depends on what the checks actually validate.
A practical review can distinguish three questions:
| Layer | Question |
|---|---|
| Resource state | Did Kubernetes create the expected objects? |
| Dependency readiness | Can the application use its database or broker? |
| Functional behavior | Does a representative user workflow succeed? |
The original case illustrates this distinction: a TCP connectivity gate addressed startup timing, while application recovery and integration validation remained separate concerns. Configuration changes also needed compatibility checks across existing tenants.
Which five companies offer useful GitOps lessons?
Customer-environment provisioning: GeekyAnts
The documented implementation offers a concrete example of provisioning customer environments from Git. Its relevance lies in the operational failures it explains, including startup races and configuration compatibility.
It provides an engineering case study, rather than evidence that any particular provisioning time or capacity applies universally.
Platform integration: Adobe
Adobe’s Flex platform combines Kubernetes with Argo CD, Argo Workflows, Argo Events, and Argo Rollouts.
Its CNCF case study describes GitOps within a broader delivery platform incorporating onboarding, service registration, secrets management, and deployment controls. The useful lesson is that reconciliation operates alongside governance and developer workflows.
Adobe provides an example of GitOps as a platform capability, extending beyond individual application deployment.
Open-source delivery tooling: Intuit
Intuit open sourced Argo CD in January 2018. Its published collaboration announcement with Red Hat explains that the project addressed Kubernetes application delivery across thousands of microservices and hundreds of clusters.
The example connects GitOps tooling with the operational requirements that motivated it: declarative delivery, visibility, and management across environments.
Enterprise distribution: Red Hat
Red Hat OpenShift GitOps uses Argo CD as its declarative engine, adding OpenShift integration, automation, and enterprise support.
Its documentation describes comparing repository configuration with live cluster state and reporting deviations for manual or automatic reconciliation.
This highlights another evaluation dimension: how GitOps tooling fits the organization’s existing platform and support arrangements.
Repository-to-cluster integration: GitLab
GitLab recommends Flux for GitOps deployments and documents its integration with the GitLab agent for Kubernetes.
This provides an alternative ecosystem to examine when teams already use GitLab for source control and delivery workflows. Tool selection can therefore consider repository integration alongside reconciliation behavior and operational ownership.
What should engineering teams evaluate next?
These examples suggest a practical evaluation exercise: test how a deployment behaves when its assumptions fail.
A useful test plan covers an unavailable dependency, an existing tenant missing a new configuration key, a failed migration, and an integration with invalid credentials.
Each scenario should establish what detects the failure, whether progress stops safely, and how recovery proceeds.
The strongest evidence comes from repeatable tests and observable application behavior. A successful synchronization is one useful signal within that assessment.
Which failure has proved hardest for production teams to catch: dependency readiness, configuration drift, migration recovery, or broken external integrations?
