Skip to content
Aabha AI Academy

Module 9 of 9 · Lesson 25 of 26

Rehearse builds, migrations and API startup

Work through rehearse builds, migrations and API startup using a runnable reference, a focused regression check and a local extension.

Read in any order. All lessons stay open, including after an unanswered or incorrect check.

In this lesson you will rehearse builds, migrations and API startup. Work with the Equipment Rental API in the downloadable lab. The reference is a complete solution with separate lesson checks, so you can inspect the answer, make a deliberate local change and verify its behavior.
Delivery needs a repeatable sequence: install or build, supply configuration, apply reviewed migrations, start the API, then check it. The Dockerfile installs the lock and copies only the runtime source and migrations. It runs the API as a non-root uid and does not embed a database URL, token key or .env file. The image command starts the app factory; it does not automatically migrate or create privileged users.

Treat schema changes as a separate controlled step. The local runner starts a fresh PostgreSQL container, applies the real migration chain and executes the lessons, then removes the test database. For an existing deployment, preserve data, verify backups and compatibility, apply migrations deliberately and retain a working rollback route. A previous image alone cannot reverse a schema change safely. Our migration downgrade refuses destructive deletion, so a rollback plan needs an appropriate forward repair or verified restore. Readiness, schema revision and a representative contract request together provide stronger evidence than a running container alone. This lesson rehearses locally and authorizes no Internet deployment.
Worked source: equipment/api.py, create_app.

Run lesson25, then python run_checks.py for the full suite. The startup check compares user counts before and after the app starts; no account is silently created. Inspect Dockerfile and .dockerignore. Optional local image build: docker build -t equipment-rental-learning:1.0.0 .; it still requires separate runtime configuration and a migrated disposable database.
pythonCopyable
def test_lesson25(db, engine):
    # Startup uses an already-migrated schema; it does not create tables or users.
    with engine.connect() as connection:
        before = connection.scalar(text("SELECT count(*) FROM users"))
    app = create_app(
        Settings(database_url=os.environ["LAB_DATABASE_URL"], jwt_secret=KEY)
    )
    with TestClient(app) as client:
        assert client.get("/equipment").status_code == 200
    with engine.connect() as connection:
        assert connection.scalar(text("SELECT count(*) FROM users")) == before
TerminalPython 3.13 virtual environment; Docker running; extracted lab directory
python run_checks.py -k lesson25

Expected result The selected lesson test passes against a new temporary PostgreSQL database; the container is removed afterward.

Keep for reference

Equipment Rental lab and lesson checks

ZIP containing Python source, real Alembic migrations, 26 lesson checks, a dependency lock and text instructions. Extract it before following the local exercise.

Download Equipment Rental lab and lesson checks

Practise locally

Build the local image and record its id plus the lock checksum. Rehearse migration and startup against a fresh database you own, check liveness, readiness and GET /equipment, then stop it. Write a rollback note explaining how you would preserve data for a schema-changing deployment. Do not reuse the platform's retained database for this lab.

The lesson check verifies the reference behavior. Add your own assertions for your change. Local practice is not uploaded or scored by this learning release.

Pause and reflect

What failure does this lesson prevent, and which assertion in lesson25 would expose it?

Use a concrete input, expected result and limitation from your local work. Saving a reflection does not certify the project.

Optional knowledge check

Which sequence fits a controlled API delivery?

Build, configure, apply reviewed migrations, start, then verify health and contracts.

Correct. Each step provides a separate check before serving database-dependent work.

Start against any database and fake-apply missing revisions if startup fails.

Try another answer. That hides incompatible schema and risks the existing data.

Run migrations automatically in every worker as it starts.

Try another answer. Separating the reviewed schema step avoids competing startup changes.

This practice does not assess your project or award a certificate.

Your reading progress

Progress is saved in this browser when storage is available.

Sign in to save across devices · Create an optional account