GitOps manages application and environment configuration by recording the desired state declaratively in a versioned source. Software agents pull that state and continuously try to make the running environment match it. This keeps operational configuration visible in version history rather than burying it in pipeline tooling. section 4.1.2
Four principles define the approach:
- Declarative: describe what should run and how it should be configured; Kubernetes manifests are one way to do this. section 4.1.2
- Versioned and immutable: retain a complete history of desired-state changes. Git is common, but a suitably versioned, immutable store can also qualify. section 4.1.2
- Pulled automatically: agents fetch changes without requiring users to time each update. section 4.1.2
- Continuously reconciled: agents observe the running system and attempt to apply the desired state. section 4.1.2
In an environment pipeline, a service pipeline first produces deployable artifacts. Configuration changes then drive deployment and promotion across environments. Argo CD is a GitOps tool for managing applications on Kubernetes; it can be used with Helm in this delivery workflow. Infrastructure as code has a different job here: creating reproducible cloud resources, including clusters, before GitOps reconciles their application configuration. section 4.0 section 4.1.2
Figure 4.5 Defining the state of the cluster using the configuration in Git (GitOps). Environment pipelines monitor configuration changes on a Git repository and apply those changes to the infrastructure (Kubernetes cluster) whenever a new change is detected. Following this approach allows us to roll back changes in the infrastructure by reverting commits on Git. We can also replicate the exact environment configuration by just running the same pipeline against another cluster.
Trace a configuration change from Git to the cluster. Reverting a commit provides a way to roll back a configuration change; applying the same configuration to another cluster can replicate the environment. section 4.1.2
A platform team can create environment repositories and assign access so application teams can promote services without installing or maintaining GitOps tooling. GitOps need not govern every interaction: a development team may still need direct cluster access. Coordinating service and environment pipelines becomes more important as releases move toward production. section 4.4
