GitOps deployment workflow¶

The GitOps deployment workflow is a modern operational model that utilizes [[Git|Git]] repositories as the single source of truth for defining declarative infrastructure and applications^[source-a.md]. In this paradigm, the desired state of the system is stored in Git, and automated processes are responsible for synchronizing the actual system state with this desired state^[source-a.md].

Core Mechanism¶

The workflow typically relies on a software agent (often running inside the cluster) to enforce the state defined in the repository^[source-a.md]. This agent continuously monitors the Git repository and the live system, detecting any divergence (known as "configuration drift") and automatically correcting it to match the committed configurations^[source-a.md]. This contrasts with traditional methods (often classified as "Push-based") where an external Continuous Integration (CI) server executes commands to push changes to the environment^[source-b.md].

Comparison of Models¶

Pull-based Deployment¶

GitOps is fundamentally a Pull-based deployment strategy^[source-b.md]. In this model, the cluster controller or agent actively polls or pulls the latest configuration manifests from the Git server^[source-b.md]. This approach eliminates the need for the CI system to possess credentials or direct access to the production cluster, enhancing security^[source-b.md].

Push-based Deployment¶

The alternative to GitOps is the Push-based deployment model^[source-b.md]. This method involves an external CI server applying changes directly to the cluster^[source-b.md]. While common, it requires granting the CI pipeline significant privileges to modify infrastructure, which creates a broader security surface compared to the pull-based agent model^[source-b.md].

Related Concepts¶

• [[Git|Git]]
• [[Continuous Delivery]]

Sources¶

^[source-a.md] ^[source-b.md]