Promote releases safely between environments

هذا الجزء لم يُترجم بعد. أنت ترى النص الإنجليزي.

$ مستخدم عادي# بصلاحية root (أو مع sudo)

Update the image tag from CI

After a green build, CI writes the new tag into the staging overlay and opens a PR for prod.

$cd shop-deploy/overlays/staging
$kustomize edit set image ghcr.io/s0sta/shop=ghcr.io/s0sta/shop:1.4.1
$git commit -am "staging: shop 1.4.1" && git push
$gh pr create --title "prod: shop 1.4.1" --body "Tested on staging." --base main --head promote/1.4.1

7.2

Automate tags with Flux image automation

Flux scans the registry, picks the newest tag that matches a policy, and commits it.

image-policy.yaml

apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImagePolicy
metadata: { name: shop, namespace: flux-system }
spec:
  imageRepositoryRef: { name: shop }
  policy:
    semver: { range: ">=1.4.0 <2.0.0" }

Argo CD has the same idea in Argo CD Image Updater.

7.3

Keep production safe

Production changes need review and a way back.

Branch protection on the config repository: PR + approval + checks.
CI checks on the config: kubectl kustomize renders, kubeconform validates, trivy config scans.
Rollback = git revert of the promotion commit.
Progressive delivery (Argo Rollouts, Flagger): canary or blue/green with automatic rollback on bad metrics.

$kubectl kustomize overlays/prod | kubeconform -strict -summary
$git revert HEAD && git push

7.4

Secure the GitOps system

Whoever can write to the config repository controls the cluster.

Risk	Control
Someone pushes a bad manifest	Branch protection, CODEOWNERS, required reviews
Fake commits	Require signed commits; Flux can verify commit signatures
Argo CD UI misuse	SSO, RBAC per project, no anonymous access
Broad agent rights	AppProjects / Flux service accounts per tenant
Unsigned images	Admission policy: only signed images (CKS supply chain)

تذكّر

GitOps moves the "keys to production" from CI into Git. Protect Git accordingly.

كل الأوامر في هذا الفصل