The path
A version moves one way: staging internal → staging external → production. You can rebuild the same version on internal until production is published. Promote keeps the same rebuild number as the latest internal build.
Staging internal
This is the only step that uses the live development work. Quiet the machine first, then:
- Check environment keys match
- Freeze Python packages
- Build the frontend
- Stamp the version
- Deploy to staging internal and health-check
A new version starts with a blank release note. Rebuilds show the current notes so you can edit them. External and production use whatever was last saved for this version.
After a successful internal build, both backend and frontend get an immutable git tag staging/{version}_r{build} (for example staging/1.0.0_r0). A rebuild is skipped when neither repo has changed since the last build.
If any step fails, it stops there and tells you where.
Before an internal build
- Stop the development backend and frontend (the local run, not staging).
- Ask other developers to close their editors so nobody saves code mid-build.
- Refresh the check until it is clear. If someone has clearly left, you can confirm that and continue.
If files change while the build is running, it will stop so mixed code is not deployed.
Staging external
Sends the already-built internal version to staging for testers. Same version and the same rebuild number as internal — Promote does not create a new rebuild. Release notes are the ones written when this version was created.
If staging external already has this internal version and rebuild, Promote is skipped — it is not an error. Rebuild internal first if you need a new promote.
Production
Not connected yet. When it is, it will publish the confirmed staging version — the same built artifact, not a new compile from development. Same release notes as this version.
When production is connected, publishing the same internal version and rebuild again should skip, same as external promote.
