Releases
Internal staging, client staging, and production.
Internal staging, client staging, and production.
Release notes
Backlog through completed. Optionally tag tasks into internal builds.
Accounts and sign-in history.
| Role | Created |
|---|
| When | Role | Event |
|---|
Commit history for development. Push never goes to main.
development branch
Your sign-ins and password changes.
| When | Role | Event |
|---|
Env check, freeze, frontend build, then deploy
Version is fixed from the internal build
Deploy is gated until a production host is connected
Commit and push to development
Short notes — no extra setup needed
A version moves one way: staging internal → staging external → production. You can rebuild the same version until production is published.
This is the only step that uses the live development work. Quiet the machine first, then:
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.
If files change while the build is running, it will stop so mixed code is not deployed.
Sends the already-built internal version to staging for testers. Same version — people cannot edit it here. Then a health check. 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.
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.