Ship It — Deploy, Package, Sustain

Review and execution boundary

This is a series hub, reviewed 8 October 2026. It teaches route selection, transitions and release/learning criteria, not the full implementation of every linked lesson. It makes no one-hour production-deployment promise. No cloud, store submission, paid service or IAM operation was executed for this review.

The API, container and desktop routes have different tooling and prerequisites. Part 4 is a separate learning-practice route, not a dependency that magically validates the other three. Reviewing this hub does not certify another file's contents or live publication. Site-wide navigation, progress behavior and release acceptance are separate integration checks.

Ship It — Deploy, Package, Sustain

A locally working script is only the beginning of distribution. Someone else needs a defined input contract, a reproducible artifact, clear configuration, predictable failure behavior and a way back when a change fails. This series explores three distribution models and a fourth route for sustaining the practice of learning from them.

Use the series page as an index, or choose one of the explicit chapter destinations below. Parts 1 and 2 share web-service concepts; part 3 is an alternative distribution path rather than a cloud prerequisite. Part 4 can be used throughout.

Who this is for

Start here if you can write basic Python but cannot yet explain how another person would install, call or recover your program. The API route develops HTTP/file-processing boundaries; containers add packaging/runtime boundaries; desktop distribution introduces compilation, linking and package identity. No prior cloud account or paid environment is needed to study the contracts. Executing optional cloud/store exercises requires separate access, cost and authorization decisions.

If HTTP or files are unfamiliar, pause at the first chapter's input/output examples. If you already operate services, skip to an unfamiliar distribution model and compare its rollback and trust boundaries. Do not mistake familiarity with Docker for Windows signing expertise.

The path

Part 1 · Script to API (~5 min, intermediate)

Deploying Scripts as an API in Azure

Move from a local function/script to a caller-visible request/response contract. Study validation, bounded uploads/work, errors, cleanup and separation between processing logic and hosting. The historical heading's five minutes is an old route label, not a current chapter duration or completion promise.

Exit evidence: explain accepted and rejected inputs, one success test, one negative test, dependency/runtime versions and what hosting/authentication behavior remains unexecuted. For a file-conversion API, a rejected oversized input is useful evidence; an HTTP 200 alone does not establish authorization, concurrency safety or resource limits.

Transition: once you know what the API needs at runtime, packaging becomes a question about which interpreter, libraries, native tools and configuration must travel with it—not merely which Docker command to copy.

Part 2 · Containers (~11 min, intermediate)

Deploying Web Applications in Azure with Docker

Study image layers, build context, multi-stage builds, runtime dependencies, least privilege, storage and startup/health behavior. Docker's documentation describes copying selected artifacts between stages while leaving unwanted build content behind. That supports the packaging mechanism, not a universal claim that a 900 MB image must become 60 MB or that smaller always means safe.

Prerequisite: part 1 helps establish an application contract but is not mandatory if you already have one. Exit evidence: identify the built artifact/digest, explain exactly what remains in the runtime image, distinguish container filesystem from persistent data, and give a startup failure and recovery test. A container running locally is not evidence that registry access, managed hosting or production traffic worked.

Transition: compare this runtime packaging with a desktop executable. A container bundles a runtime environment; a Windows program/package has compilation, linking, platform and installation contracts. They solve different distribution problems.

Part 3 · Desktop and the store (~7 min, intermediate)

Building a Windows App and Publishing to the Store

Follow source → object files → linking → executable, then installation/package identity and store submission. Understanding what the compiler emits helps distinguish a compile error, unresolved symbol, missing runtime dependency and packaging/signing failure. None is fixed merely by uploading the file again.

Exit evidence: a reproducible build description, architecture/runtime requirements, clean-machine installation/uninstallation/update tests and a package identity/signing plan. A successful .exe launch does not certify Store acceptance. Microsoft's current publishing overview distinguishes submission choices including MSI/EXE and MSIX; determine the applicable path and its requirements for the actual app.

Transition: after any distribution exercise, record what you can reproduce and what you had to look up. That evidence—not the number of pages visited—drives the next learning session.

Part 4 · Sustaining it (~30 min, intermediate)

Building a Learning System That Actually Sticks develops the companion study routine: retrieval practice, spaced review, an error log and realistic scheduling. Read it alongside this hub when you want the reasoning and worked planning examples behind the routine below.

The hub's purpose is to connect shipping practice to retrieval, spaced review and scheduled revision. Use these as an explicit study routine, not a guarantee about every learner or an unsupported claim that “most self-study fails at retention.” A 26-week schedule is a planning framework, not a universal learning deadline.

1. Before rereading, explain a mechanism on a blank page: for example, why a runtime stage needs a native conversion binary. Write uncertainties rather than guessing that you remember.
2. Attempt a bounded task, such as designing an invalid-upload test or tracing a missing-library startup failure. Compare with the chapter's worked answer and record the specific error.
3. Schedule retrieval again after a gap—for example after two days, one week and one month. These are adjustable planning examples, not empirically optimal intervals for everyone. Bring a repeatedly missed concept forward and avoid spending every review on what is already easy.
4. Reserve revision sessions within a longer plan. Rebuild the explanation/test without copying, check the result, and use the error log to choose the next task. Count demonstrated work, not clicks or reading streaks.

Worked example: you can launch a container but cannot explain why rebuilding did not alter a running instance. Write “image artifact versus running container” in the error log; draw the two identities; predict what changes after a rebuild, replacement and volume reuse; compare the chapter's explanation; revisit the same question next week without notes. If you can explain it but have never run a replacement test, record concept explained; runtime test unexecuted, not “deployment mastered.”

Part 4 can be read before, during or after parts 1–3. This self-contained transition and exercise complete the hub's learning-purpose scope; they do not replace or certify the companion's full treatment.

How to read this series

Choose a route, read its prerequisite contract, attempt the worked exercise before its answer, and retain a short evidence note: input, predicted outcome, observed outcome, discrepancy and next check. Return through the explicit chapter links; this source review does not promise that every global previous/next widget has passed integration testing.

If you have one hour, study one contract and one negative case. Do not compress hosting, authentication, paid-resource setup and recovery into a promised one-hour deploy. Historical minute labels above are retained for route continuity; use the destination's current metadata and the task's complexity to plan time.

Cloud prices, product versions, store rules and portal screens change. Recheck the exact current service contract before executing an optional exercise. Use supported credential setup, do not embed credentials in examples, and do not create a resource merely to mark a lesson complete. A clearly labelled conceptual exercise is valid progress.

What this series does not cover

• Complete CI/CD and rollout orchestration: continue into the Microsoft/cloud delivery material through the 6-month plan. This hub does not implement a pipeline.
• Kubernetes at scale: understand the container contract first, then study orchestration, configuration, networking and recovery separately.
• Full monitoring/on-call practice: service-level objectives, alert design and incident response need their own treatment; shipping is not the end of operations.

These subject boundaries avoid the old hub's stale module-number claims. They are route guidance, not certifications of the whole learning graph.

Corrected contracts and failure analysis

All three distribution paths need a reproducible artifact, declared runtime dependencies, bounded inputs, appropriate access, observable failure and a recovery procedure. The concrete checks differ: an API needs request/auth/concurrency boundaries; a container needs image/runtime/storage/probe checks; desktop distribution needs platform, package identity, installation and update checks.

A recovery plan must name what it can recover. Reusing an old image may revert code but not a database migration. Reinstalling an old desktop package may fail against newly migrated user data. A learning log should expose these limitations rather than record a green command as universal success.

Boundary exercise with solution

What release evidence would you require before giving a colleague an artifact, and what should the next study session be if something fails?

Worked answer

Record the artifact hash, source/build/runtime versions, dependency manifest, configuration instructions without embedded secrets, exact smoke/negative tests and results, known execution limits and rollback/data-compatibility constraints. If startup fails because a native binary is missing, add a runtime dependency check and reproduce it against the intended artifact. Revisit the packaging mechanism without notes in a later revision session. A screenshot may supplement this evidence but cannot replace it. If cloud hosting was not executed, label it unexecuted rather than infer it from a local pass.

Open the full series →

Source-backed review notes

• Docker multi-stage builds: multiple FROM stages and selective artifact copying support the packaging mechanism, not a guaranteed size/security result. Saved official source reused with raw-hash and extraction checks on 8 October 2026.
• Microsoft Store publishing overview: different submission options have different requirements; a compiled executable is not automatically a Store-approved package. Saved official source reused and reprojected on 8 October 2026.
• The retrieval/revision schedule here is a transparent worked study recommendation, not a new efficacy estimate or a substantive review of the separately owned learning-system chapter.