In a GitOps workflow, how should application environments be managed when promoting an application from staging to production?

The core principle of GitOps is using a Git repository as the single source of truth for the desired state of an application. The promotion of an application from a staging to a production environment is managed through Git operations. Typically, a pull request is created to merge the validated configuration from a staging branch into the production branch. Once this merge is approved and completed, a GitOps operator (e.g., Argo CD, Flux) automatically detects the change in the production branch. It then pulls the new declarative configuration and applies it to the production cluster, reconciling its live state with the newly defined desired state in Git.

B. Creating a new production environment for each update is inefficient, costly, and not a standard GitOps practice, which focuses on updating a persistent environment's state.

C. Manually updating configuration files directly in the environment breaks the fundamental GitOps principle of using Git as the single source of truth, leading to configuration drift.

D. This describes a traditional push-based CI/CD model. GitOps primarily uses a pull-based model where an agent inside the cluster pulls changes from Git, rather than an external tool pushing them.

1. OpenGitOps Principles v1.0.0

The GitOps Working Group

CNCF:

Principle 1: "The desired state of a system must be: 1. Stored declaratively

2. Versioned and immutable

3. Pulled automatically

4. Continuously reconciled." The act of merging changes in Git updates the versioned

declarative state

which is then pulled automatically by the operator.

Reference: opengitops.dev

section "The GitOps Principles".

2. Argo CD - Official Documentation:

The documentation describes common GitOps patterns

including managing environments. The "Branch per environment" pattern explicitly states: "Promotion of changes across environments is done by merging changes from the development branch to the staging branch

and finally to the production branch. The GitOps tool automatically deploys the changes to the environment after the merge."

Reference: Argo CD Documentation

"User Guide"

section "Managing Environments".

3. Flux CD - Official Documentation:

The documentation on structuring repositories for GitOps workflows explains how to manage different environments. It details that "Promoting a new version of an application to an environment is a matter of updating the image tag in that environment’s Kustomization file and committing the change to Git." This commit is often the result of a merge from another branch.

Reference: Flux CD Documentation

"Guides"

section "Structuring your repositories".