Memory hook: CI proves the change; delivery prepares it; deployment releases it; GitOps keeps reality aligned.
Must remember
- Continuous integration, CI, merges and validates changes frequently through automated builds and tests. Continuous delivery keeps a validated release ready, often with a human approval before production. Continuous deployment automatically releases qualifying changes to production.
- A typical path is commit → build → test/scan → immutable artifact → deploy → verify. Build once and promote the reviewed artifact when possible. Rebuilding separately for every environment risks deploying content different from what was tested.
- GitOps uses declarative desired state kept in version control, with agents pulling that state and continuously reconciling the live system. Git history supports review and traceability; the reconciler detects and corrects drift.
- Argo CD and Flux are recognisable GitOps delivery projects. A CI script that runs
kubectl applyis automation, but it does not by itself provide continuous pull-based reconciliation. - Helm packages applications as charts with templates and values, and tracks installed releases. Kustomize composes and patches Kubernetes manifests using bases and overlays without requiring a general template language. Either can supply desired manifests to a delivery process.
| Strategy | What changes | Main trade-off |
|---|---|---|
| Recreate | Stop the old version, then start the new | Simple, but may cause downtime |
| Rolling update | Replace instances gradually | Old and new versions may coexist |
| Blue-green | Prepare a second environment, then switch traffic | Fast switch or reversal, but extra capacity |
| Canary | Send a limited share of users or traffic to the new version | Lower initial exposure, but needs measurement and traffic control |
- Kubernetes Deployments support rolling updates and recreates. A meaningful canary requires a deliberate way to control exposure and judge results; simply creating a new Pod is not a complete release strategy.
maxSurgecontrols temporary extra replicas during a rolling update;maxUnavailablecontrols permitted unavailability. Readiness helps prevent premature traffic to new Pods. Resource headroom matters when old and new replicas overlap.- Rollback restores a prior application configuration or artifact. It does not automatically reverse database schema migrations, external messages or user-visible data changes. Design compatibility and recovery before releasing.
- Secure the supply chain with reviewed dependencies, trusted registries, image scanning, provenance/signature checks and least-privilege pipeline credentials. SBOMs describe software components; they are not proof that a release has no vulnerabilities.
- Deployment success needs observation: healthy Pods are necessary but do not alone prove acceptable latency, error rate or business behaviour.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Automatically detect and repair changes made outside reviewed manifests | A GitOps reconciler |
| Install a configurable, reusable application package | Helm chart and release |
| Maintain environment-specific manifest changes over a shared base | Kustomize overlays |
| Expose only a small share of production traffic initially | Canary with explicit traffic control and success criteria |
| Switch back quickly while keeping an old environment available | Blue-green, with a compatible data strategy |
Traps
- Continuous delivery does not necessarily mean automatic production deployment.
- Git is not a secret manager; plain credentials in repository history remain exposed even after a later deletion.
- An automatic rollback cannot safely undo every stateful business operation.
- An image scan and a successful deployment are different checks; neither replaces runtime monitoring.
Active recall
1. Builds and tests are automatic, but a person approves production release. Is continuous delivery an appropriate description?
Yes. Continuous delivery keeps the change ready for release and can retain a manual gate. Continuous deployment normally removes that manual production gate for qualifying changes.
2. Someone edits a live Deployment outside Git. Which pattern can notice and restore the repository's intended state?
GitOps with a continuously operating reconciler such as Argo CD or Flux. The repository supplies desired state, and the controller detects divergence according to its configured policies.
3. A team wants to send 5% of traffic to a new version and compare errors before expanding. Which release approach fits?
A canary release with explicit traffic shaping, observability and promotion/rollback criteria. Having two versions exist does not alone guarantee the intended traffic proportion.
4. A rollout uses additional Pods, but no nodes have spare capacity. Why can progress stall?
The temporary surge replicas may not fit. Check resource requests, node capacity and rollout availability settings; the strategy's required headroom is part of release planning.
5. Does restoring the previous image necessarily undo a destructive database migration?
No. Application rollback and data recovery are separate. Use compatible migrations, tested backups or another planned recovery mechanism for stateful changes.