MAIE6000C Chap.9 Reproducible Deployment
Reproducible Deployment
The standard, stated twice and bluntly
Engineering has not really happened while a system leans on machine state nobody recorded, setup moves nobody wrote down, or the particular laptop of one member of the team. And reproducibility is not there yet while exactly one person on the team can start the thing.
Both sentences are claims about the repository rather than about the code, which is why the week's work is an audit rather than a feature.
The clean-clone procedure, gate by gate
Clone into an empty directory, which proves nothing outside version control is required. Copy the example configuration, which proves no secret exists only on your machine.
Check that the configuration parses, which proves no machine-specific path is baked in. Build and start the services, which proves no image was built by hand. Apply the schema, which proves no table was created manually. Then submit one item end to end, which proves no step is being performed off screen.
Each gate proves one negative, which is why the order matters and why the exercise has to start from nothing.
Containers are a documentation decision
The taught vocabulary is deliberately plain: an image is the recipe, a container is a running copy of that recipe, and the multi-container tool runs several together, in this case the request-handling service, the database, the worker and the internal AI service.
What that buys is not isolation for its own sake.
The recipe is a file in the repository, so a reviewer reading it can see every dependency the system has, which is the question the operations document exists to answer and the one a hand-built environment makes unanswerable.
Reset has two levels and the difference matters
Stopping and removing containers is one operation; also removing the stored data is a different one, and the course flags that the second should be used carefully.
That distinction is what makes the clean-clone test possible at all, because a project whose database volume survives every restart has never been observed starting from an empty schema.
Most first-time clean runs fail at exactly that gate, because a table somebody created by hand months earlier has been quietly present ever since.
The hidden dependency is never exotic
In a semester project it is one of five things: a table created by hand, a configuration value that exists only in one person's environment file, a data file outside version control, a locally built image nobody described, or a command somebody runs before the demonstration and has stopped noticing.
None is difficult to fix once named, and all five are invisible from the inside. That is why the procedure begins by destroying the thing you are standing on rather than by reading code.
Release candidate thinking, eight weeks early
The module asks you to prepare a cleaner release candidate, which in a semester project means a state of the repository you would be willing to have assessed without warning.
Applying that standard from Week 9 onward is cheap insurance, because the final milestone and the oral defence both inspect a tagged state rather than a demonstration, and a team that keeps the main line in that condition never has a bad week to explain.
What this chapter covers
- 01
Six clean-clone gates, and the negative each one proves
- 02
The published three-command startup path and the two health payloads
- 03
Which tools you install locally and which run inside containers
- 04
Images, containers and the multi-container tool in plain terms
- 05
The two reset levels, and why the second makes the test possible
- 06
Five hidden dependencies that account for almost every failure
- 07
What the operations document has to answer
- 08
Release candidate thinking from Week 9 onward
A clean clone that starts and then cannot answer
- 2Say what the successful start already rules out.
- 3Explain why the team never sees this failure.
- 3Give the repair and the way to prove it.
Key terms
- Clean Clone
- A start from an empty directory on a machine that has never run the project, which is the only test that exposes hidden local state.
- Environment File
- The configuration a service reads at startup, supplied as an example in the repository so that no value exists only on one person's machine.
- Container Image
- The recipe from which a running container is created, described by a file in the repository so that every dependency is visible to a reader.
- Release Candidate
- A repository state the team would be willing to have assessed without warning, which is a useful standard from the deployment week onward.
- Operations Document
- The required repository file answering how to run the system, how to test it, and what is and is not currently supported.
- Hidden Dependency
- State a system needs that exists outside version control and outside the written instructions, and is therefore invisible to everyone except the machine that has it.
- Startup Migration
- Applying schema changes as part of bringing the system up, which is what makes an empty database reach the shape the application expects.
Reproducible Deployment FAQ
What does a clean-clone test actually prove?
Each step proves one negative, which is why the order matters. Cloning into an empty directory proves nothing outside version control is required. Copying the example configuration proves no secret exists only on your machine. Checking that the configuration parses proves no machine-specific path is baked in. Building and starting proves no image was built by hand. Applying the schema proves no table was created manually.
Submitting one item proves no step is being performed off screen. Skipping to the last step on a machine that already works proves only that the machine already works.
Why did my system work for months and fail on a reviewer's machine?
Almost always because a piece of state has been quietly present on the team's machines since early in the semester. The five usual candidates are a database table created by hand, a configuration value that exists only in one person's environment file, a data file sitting outside version control, a container image built locally and never described, and a command somebody runs before the demonstration and has stopped noticing.
None is hard to fix once named, and all five are invisible from inside, which is why the audit starts by destroying your own local state rather than by reading code.
Do I need to install the database and the framework myself?
No. The course states that the application framework, the server, the database, the object-relational layer, the migration tool and the test runner come with the supplied repository and execute within containers, so installing them individually creates version conflicts you then have to debug.
What you install locally is a version-control client, a container runtime with its multi-container tool, a code editor, and optionally a recent Python interpreter for editor support. Three version-check commands confirm the prerequisites, and the starter itself is verified by copying the example configuration and starting the stack.
Assessment move
Do the clean-clone run twice: once in Week 9 to find the gaps, and once in the week before the final demonstration on the machine you will present from. The second run is not paranoia. Almost every demonstration failure in a project of this shape is local state that was working right up to the moment somebody else's laptop was plugged in.
Working through Reproducible Deployment in MAIE6000C? Sia is AskSia’s AI Computer Science tutor — ask any MAIE6000C Reproducible Deployment question and get a clear, step-by-step explanation grounded in how MAIE6000C is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
