One path, end to end
The capstone path
The capstone is the exam for the whole path: build an image, declare the workload, commit the desired state and let a controller reconcile it. Nothing new — the same tools, in the order production uses them.
From artefact to desired state
A container image is the artefact; a Kubernetes Deployment is the declaration of how many copies should exist; Git is where that declaration lives. GitOps adds the last step: a controller compares the cluster to the repository and corrects it.
The deliverable is not 'it deployed once'. It is 'the repository describes the cluster, and the cluster converges to it' — which is what makes rollback a revert instead of an SSH session.
Evidence over claims
Every stage should leave something checkable: a tagged image, a workload reporting ready replicas, a commit that carries the manifests, a sync status.
If you cannot point at the artefact and the state, you have a demo, not a delivery path.
Commands in this lesson
Every one of these runs in the sandbox — no real account, no real bill.
| Command | Why |
|---|---|
docker build -t ophir/capstone:1.0 . | A tagged artefact — the thing every later stage refers to. |
kubectl apply -f k8s/deployment.yaml | Declare the workload; the cluster reconciles to it. |
git add k8s && git commit -m 'deploy capstone' | The desired state is reviewed and versioned like code. |
git push origin main | Publish the declaration; a controller can now converge on it. |
Now do it
Reading the model makes the first attempt faster. Only the lab makes you able to do it.
- Open the lab
Capstone: Build, Commit and Sync a Service
Advanced · 45 min · members
- Open the lab
Capstone: DevSecOps Pipeline with Security Scanning
Advanced · 45 min · members
The capstone path · OphirCloud Academy · all lessons