Rullst AcademyRullst Academy/Lesson
From application to release with Rullst · Lesson 11 / 12

Update with a known way back

Rolling back a program and rolling back data are different decisions. Let’s rehearse a small change without hiding that difference.

Learning paths35 min

Let's discover together

  1. 1

    Before changing code, build the initial version and preserve its executable in a new v1 folder outside target as shown in README. Record its hash. Use only a restored database copy for rehearsal.

  2. 2

    Change only visible text in web/index.html, without touching schema.sql, routes or data rules. Run tests and rebuild. Stop v1, select MB_RELEASE=lesson-v2 and run the new binary against the lab copy.

  3. 3

    Check /readyz, changed text and missions. Add a fictional mission in v2. Stop v2 and run the preserved v1 binary with MB_RELEASE=lesson-v1 against the same copy. The new mission should remain because the schema did not change.

  4. 4

    MB_RELEASE can lie if you choose the wrong value. Also compare compiled text and executable hash. Do not treat changing only a variable as deploying new code.

  5. 5

    If a future update changes schema, this rollback may fail. Stop and assess compatibility, later writes and rehearsed recovery before deciding. Restoring an old backup can discard recent changes; do not automate that decision blindly.

From reasoning to execution

The core path runs on your computer with fictional data. Podman, Quadlet and Caddy are optional extensions; no domain purchase or cloud subscription is needed. This lab is not ready for public writes.

Read the steps before running anything. The commands below are a reference; README.md explains your OS syntax and LAB.md contains the sequence. The site does not run these commands for you.

cargo test --locked
cargo build --release --locked
My evidence record

Record v1/v2 hashes, observed text, added mission and rollback result. Add an explicit stop condition: “if there is a data migration, verify compatibility before rollback”.

Separate prediction, execution and observed result. Record “not executed” when the environment is missing. Site progress does not validate real deployment or grant professional certification.

My files and GitHub

Official links and next step

✦
YOUR MISSION

Test two versions against a lab copy and justify when rollback is compatible.

Now it's your turn

Discovery workshop

Decide using evidence

v2 added a mission using the same schema. A plan proposes automatically restoring the earlier backup.
Build your answers and check when you are ready.
A moment to understand

When does this lesson’s rollback preserve the mission created in v2?

I need a hint

This exercise changes presentation while keeping schema. It rehearses program rollback without confusing data rollback; it does not prove compatibility of future migrations.

Loading your journey…

Take it with you

Record v1/v2 hashes, observed text, added mission and rollback result. Add an explicit stop condition: “if there is a data migration, verify compatibility before rollback”.

At your own pace

My files and GitHub

Every lesson can become your own record: code, notes or a practice plan. Saving a file to GitHub is optional and does not change your XP.

Student guide

The editor and downloads open when this lesson is available to your account. Check access below or return to the track map.

Checking your access to this lesson…

Rullstpetbot

AI can make mistakes. Check the lesson material.