Tester guide

The release console lets you assemble a datafi release (one version each of frontend, co and ed), try it on stage, and queue it for production. Nothing here talks to production directly: production changes only when a ready release is promoted (Start prod deploy in the console, or prod_promote in GitHub Actions).

Environments

Name	What it is	URL
dev	Where every new build lands automatically. Component CI bumps it whenever a build finishes.	site-dev.datafi.us
stage	For now, the same infrastructure as dev. "Deploy to stage" points dev at your release's versions.	same as dev
prod	Customers. Only changed by the promote step.	home.datafi.us, releases.datafi.co

Because stage is dev, deploying a release to stage replaces what other developers see on dev until you restore it. Tell the team before you stage, and restore when you are done testing.

Release lifecycle

Status	Meaning	Available actions
draft	Being assembled or tested.	Deploy to stage, Restore previous dev, Ready for prod, Abandon, edit notes
ready "ready for prod"	Queued for the next production promote. Oldest ready release goes first.	Start prod deploy, Deploy to stage, Restore, Unready, Abandon (until promoted)
ready + promotion requested or applied "deploying to prod"	Promotion has been requested or applied; production deploys are starting, running or finished. Waiting for the manifest to publish. While only requested, Unready is still available.	Unready (until applied); Restore previous dev, disabled only while a promotion requested from the console is still pending
released "live in prod"	Live in production and published to releases.datafi.co.	Restore previous dev while dev is still on this release
abandoned	Dropped. The number cannot be reused.	Restore previous dev while dev is still on this release

1. Create a release

Dashboard, then New release.
Pick a version per component. The list shows recent builds that reached dev; the current dev version is preselected.
The datafi version is suggested for you (next patch, or next minor if a component changed major). You can edit it: it must be plain X.Y.Z, higher than what production has, and not used by another release.
Add notes (what is in it, what to test) and Create.

Creating a release changes nothing on any environment. It only records the set.

2. Deploy to stage and test

Open the release and click Deploy to stage. The dialog lists exactly which components will change and their current dev versions. Components already on stage are skipped.
Confirm. The console commits the change and the dev deploy workflows start. Run status shows on the stepper next to the step, with a GitHub Actions link for detail; a rollout of co or ed takes 5 to 10 minutes.
The component table shows on stage per component once dev matches the release.
Test on dev. Fix builds land on dev automatically through CI and will show as drift (the badge flips back to differs); create a new release if you need the newer build.

The first stage deploy snapshots the dev versions it replaced (the previous dev column). Redeploying does not overwrite that snapshot.

3. Restore previous dev

When you are done testing, click Restore previous dev. It puts dev back to the snapshotted versions and runs the dev deploys again. Only components that are still at your release's version are restored; a component that CI has since moved forward is left alone and listed as skipped, so you never undo someone's newer build.

If a release was cut from what dev already held, the snapshot is a no-op: dev was never changed, so there is nothing to put back. The console records the dev track version for those components instead - the last version dev/<component> held that is not this release's - and the restore dialog offers to roll back to it behind a checkbox. It is off by default, because dev may have moved to that version on its own rather than for this release. The components table shows the value under Previous dev. This works for older releases too: the value is read from dev/<component> history when the record does not carry one.

Restore only writes dev/<component>, never prod, so no status takes it away: if you promoted, rejected or abandoned before restoring, open the release and click Restore previous dev then. It disappears only once there is nothing left to put back.

Instead of continuing, you can also click Reject on a staged draft to abandon it with a required reason. Rejected releases cannot be reused.

4. Ready for prod

Ready for prod queues the release for production. The console checks the version rules first and shows the reasons if the release cannot be marked ready (for example a pre-release component). Several releases can be ready at once; they form a queue, oldest first. Unready takes it back out of the queue until it is promoted.

5. Start prod deploy

From a ready release, click Start prod deploy. A panel shows the plan: which components will change in production, and any warnings or blockers. Type the datafi number to confirm, then Confirm prod deploy. This dispatches prod_promote (GitHub Actions) for that specific release.

The stepper shows the prod_promote run, then the production deploy runs, as they happen.
The workflow writes the release's component versions to production and stamps the release as promoted (status pill: "deploying to prod").
When every deploy has succeeded, prod_promote starts prod_release_publish, which publishes the release's datafi number to releases.datafi.co and flips the release to "live in prod".

If a release's components are all already in production, promoting it only publishes the new datafi number.

Prod deploy and Live in prod are two different things. Prod deploy ticks when the versions have been written to production; watch the run rows under the step for the rollout itself (co and ed take several minutes). Live in prod means the datafi number is published on releases.datafi.co, which is what the Terraform installer reads, so tenant installs and upgrades only pick the release up at that point.

See docs/promote-to-prod.md for the Actions-only path (from_dev, force_dispatch, or when the console is down).

Version rules

Component versions: X.Y.Z, optionally with a suffix such as 4.2.1-rc1.
A version with a suffix, or containing next or test, is a pre-release. It can be staged but cannot be marked ready; production only takes final versions.
Datafi version: plain X.Y.Z, greater than the number production has, unique across all releases including abandoned ones.

Reading the dashboard

Component cards: prod and dev/stage pins per component, plus a stats strip (drafts, ready queue, on stage). ahead of prod means dev has a newer build than production; pre-release marks a version that cannot go to production.
Releases: status, queue position for ready releases, the component set, who created it and when. Click the datafi number for details.
A draft with a cannot mark ready badge fails a version rule; hover the badge for the reason.

FAQ and troubleshooting

I get "not in the Release Console Testers group"

Ask an admin to add your datafi.co account to the group, then sign out and back in.

Deploy to stage says done but dev still shows the old version

The deploy workflow is still rolling out. Check GitHub Actions; ECS rollouts take several minutes. If a run failed, post its link in the devops channel.

The suggested datafi number looks wrong

It skips numbers already taken by any release, including abandoned ones. Edit the field if you want a different number that still follows the rules.

Can I stage a release that is already marked ready?

Yes, until it is promoted. After promotion the release is read only.

Something I did should not have happened

Every action is a commit on datafilabs/deploy authored as you; the toast after each action links to it. Post the commit link in the devops channel.