Skip to main content

PR-Based Workflows & Change Calendar

Purpose: For operators, shows how to implement PR-based change management with branch strategies and approval workflows.

Why PR Workflows Matter​

In a GitOps model, the Git repository is the source of truth. Every change to a cluster — service upgrades, configuration tweaks, new applications — flows through a Git commit. PR workflows add review, approval, and audit trail to that process. Nothing reaches the cluster without passing through a merge.

Branch Strategy​

openCenter repositories use a trunk-based model with short-lived feature branches:

  • main — The production branch. FluxCD reconciles from this branch.
  • feature/*, upgrade/*, fix/* — Short-lived branches for changes. Merged via PR after review.
# Create a branch for a service upgrade
git checkout -b upgrade/cert-manager-v1.16

# Make changes, commit, push
git add applications/overlays/<cluster>/services/sources/opencenter-cert-manager.yaml
git commit -m "chore: bump cert-manager to v1.16.0"
git push origin upgrade/cert-manager-v1.16

PR Review Process​

Required Checks​

Configure your Git hosting platform (GitHub, Gitea, GitLab) to require:

  1. At least one approval from a platform team member
  2. CI validation — Run opencenter cluster validate in CI to catch configuration errors before merge
  3. No direct pushes to main — All changes go through PRs

What Reviewers Check​

  • Does the change match the stated intent (commit message, PR description)?
  • Are secrets encrypted with SOPS (no plaintext credentials in the diff)?
  • For version bumps: has the new version been tested in staging?
  • For infrastructure changes: is the Terraform plan attached or summarized?

Gating Deployments with Merge Timing​

FluxCD reconciles as soon as changes appear on the target branch. To control when changes reach the cluster, control when PRs are merged:

  • Maintenance window deployments — Approve the PR ahead of time, merge during the window.
  • Staged rollouts — Merge to the staging cluster overlay first. After validation, open a separate PR for production.
  • Emergency changes — For urgent fixes, a single reviewer can approve and merge immediately. Document the reason in the PR.

Example: Infrastructure Change PR​

# Edit Terraform variables
vim infrastructure/clusters/<cluster>/main.tf

# Validate before committing
opencenter cluster validate <cluster-name>

# Commit and push
git checkout -b fix/increase-worker-disk
git add infrastructure/clusters/<cluster>/main.tf
git commit -m "fix: increase worker node disk to 200GB"
git push origin fix/increase-worker-disk

The PR diff shows exactly what infrastructure changes will be applied. Reviewers can assess impact before approving.

Example: Service Configuration PR​

# applications/overlays/<cluster>/services/kyverno/override-values.yaml
# Adding a new policy exception
admissionController:
  replicas: 3  # Scaled up from 2
git checkout -b config/kyverno-scale-admission
git add applications/overlays/<cluster>/services/kyverno/override-values.yaml
git commit -m "config: scale Kyverno admission controller to 3 replicas"
git push origin config/kyverno-scale-admission

Audit Trail​

Every merged PR creates a permanent record of:

  • Who proposed the change
  • Who approved it
  • What changed (full diff)
  • When it was merged (and therefore when FluxCD applied it)

This audit trail satisfies change management requirements for regulated environments. Cross-reference PR merge timestamps with FluxCD events to trace exactly when a change reached the cluster:

# Find when FluxCD applied a specific revision
kubectl get events -n flux-system --field-selector reason=ReconciliationSucceeded

Verification​

After merging a PR, confirm FluxCD picked up the change:

# Check the latest applied revision matches the merge commit
flux get kustomizations -A

# For HelmRelease changes
flux get helmreleases -A

If the revision does not advance within the reconciliation interval (default: 10 minutes), check the source and controller logs.