← All learning paths

Intermediate · 4 steps

CI/CD foundations

Follow a change from a bounded product through durable execution to observable delivery.

Before you start
Git, basic containers, and familiarity with a CI pipeline.

What you will make
A delivery design that names its failure boundaries and keeps evidence of what ran.

Open My Learning →

  1. 01 · Book chapter

    Model a run before writing a script ↗

    Give each CI run explicit inputs, identity, and an observable outcome.

    Put it to work

    Describe the source revision, pipeline snapshot, and artifact produced by one run. Distinguish the run from a worker's particular attempt to execute it.

    Keep as evidence: A run record that makes its inputs and outcome inspectable.

  2. 02 · Book chapter

    Make an attempt identifiable ↗

    Distinguish a job from a particular worker attempt so late results cannot silently win.

    Put it to work

    Draw a timeline with a timed-out attempt, a replacement, and a late result. Mark which writes each attempt may perform.

    Keep as evidence: A timeline that identifies the ownership check at every state-changing write.

  3. 03 · Worked scenario

    Investigate a timeout ↗

    Preserve uncertainty when a remote action outlives the request waiting for it.

    Put it to work

    Write a recovery checklist that observes the actual target before deciding to retry a deployment.

    Keep as evidence: A checklist that cannot accidentally assume a timeout means nothing happened.

  4. 04 · Open-source project

    Inspect a concrete GitOps implementation ↗

    Map build execution, image evidence, and deployment intent onto distinct components.

    Put it to work

    Read the pinned project sources. Map each architecture step to a resource or component and identify where credentials are needed.

    Keep as evidence: An annotated architecture sketch and a list of prerequisites for a local trial.

    Practice in the browser

    Automate release evidence →

Pause and check

Follow the evidence through a failure

Choose an answer for every scenario, then check your reasoning. Progress is saved only in this browser.

1. The deployment request times out. What can you conclude about the remote side effect?
Explanation and further reading

A timeout describes how long the caller waited. Recovery must inspect the target and preserve uncertainty before deciding whether to retry.

Revisit the guide or chapter →
2. An old worker finishes after a replacement has acquired ownership. Where must ownership be checked?
Explanation and further reading

An expired attempt can still be running. A fencing check at the write boundary prevents a stale attempt from publishing an authoritative result.

Revisit the guide or chapter →
3. Which field would make a content-only release manifest differ on every rebuild?
Explanation and further reading

A current timestamp changes even when artifact evidence does not. Fixed fields and deterministic ordering allow equivalent inputs to serialize identically.

Revisit the guide or chapter →
4. A pipeline definition changes while a run is queued. What should identify the original work?
Explanation and further reading

A run record binds work to explicit inputs. A mutable branch or pipeline name cannot by itself explain what a queued run was supposed to execute.

Revisit the guide or chapter →
5. A worker retries a job after losing its lease. Should it reuse the previous attempt's authority?
Explanation and further reading

The job and its execution attempt are different identities. Fencing protects writes when an older attempt continues after replacement.

Revisit the guide or chapter →
6. A stale worker reports success after a replacement has failed. Which result may become authoritative?
Explanation and further reading

Arrival order is not ownership. The state-changing boundary must reject results from an attempt that no longer owns the write.

Revisit the guide or chapter →
7. A deployment timed out and a retry could duplicate the side effect. What should recovery do first?
Explanation and further reading

Inspecting the target preserves uncertainty and avoids equating a lost response with a missing side effect.

Revisit the guide or chapter →
8. Two releases use the same filename but different file contents. What distinguishes the published evidence?
Explanation and further reading

Artifact names can be reused. Content evidence and source identity let a reviewer distinguish what was actually produced.

Revisit the guide or chapter →
9. An image builds successfully, but the deployment target has not converged. Which statement is accurate?
Explanation and further reading

Cloudivision separates build execution, image evidence, and deployment intent. Inspect the target observation instead of inferring it from a build result.

Revisit the guide or chapter →
10. A caller cancels a deployment request. What evidence would establish that the remote action also stopped?
Explanation and further reading

Ending the caller's wait does not establish the remote outcome. Recovery needs evidence at the boundary where the side effect runs.

Revisit the guide or chapter →

Your checklist is saved only on this device. Keep your own evidence alongside each exercise. Follow new guides →