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 happen when an operator runs the promote step at the deploy window.

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, Mark ready, Abandon, edit notes
ready	Queued for the next production promote. Oldest ready release goes first.	Deploy to stage, Restore, Unready, Abandon (until promoted)
ready + promoted	The operator has promoted it; production deploys are running or finished. Waiting for the manifest to publish.	none (read only)
released	Live in production and published to releases.datafi.co.	none
abandoned	Dropped. The number cannot be reused.	none

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. Watch progress under GitHub Actions; 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.

4. Mark ready

Mark ready 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 the operator promotes it.

5. What happens at the deploy window

The operator runs prod_promote (GitHub Actions). It takes the oldest ready release, or a specific one if named.
It writes the release's component versions to production and stamps the release as promoted. Production deploys run.
When the deploys succeed, prod_release_publish publishes the release's datafi number to releases.datafi.co and flips the release to released.

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

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.