Test and live
Try everything in test, then move it to live, where your real members are.
Every project has two environments, test and live. Test is your rehearsal space: build a quiz, try it with pretend members, and change your mind as often as you like. Live is what your real members use.
Each environment keeps its own members, progress, points, rewards, settings and history, so nothing you try in test touches a real member.
In live, Console marks every project page with a mint strip along the top of the header and a Live badge beside the page title, and confirmations for actions that affect members name the environment they apply to.
What you can change in live
Changes come in two kinds:
- What your program is, such as a quest, its reward, a badge, or a leaderboard. You change these in test, and a person on your team moves them to live with a promotion.
- Running the program day to day, such as pausing a quest, reviewing submissions, correcting a member's points, or managing a group. You do these directly in live.
| Kind | Examples | In live |
|---|---|---|
| Definitions | Quests, their settings values and archive state; Quest Studio drafts; point ledgers; badges; the project calendar; profile settings; pickup policy; stock items; a leaderboard's exclusion-group binding; archiving or restoring any resource | Refused for every credential, Console included. Make the change in test, then promote it. |
| Operations | Pausing and resuming quests, redemptions, offers and trackers; point changes; attempt review; settlement approval; member and profile moderation; reward corrections; stock corrections; groups and their members; badge awards; referral controls | Accepted under the caller's permissions. |
| Promotions | domino promote, management.promotions.prepare | Prepared from test with every definition. A person approves each one in Console. See promotion. |
| Code deployments | domino deploy --environment live, management.deployments.preview | Refused for every credential, Console included. Deploy to test, then promote. See Publish behavior to live. |
| Environment settings | Integrations, webhooks, member sign-in, hosted-app secrets | Set in each environment on its own. A promotion never copies them; it warns when live lacks one test uses. |
| Plugin connections | Integrations, domino connections, management.connections | Connected in each environment on its own, with its own secrets or access granted at the service. A promotion never copies one and doesn't warn when live lacks one, so connect live yourself. |
Looking things up and previewing changes work in live too, because they change nothing.
- Definitions reach live through a promotion. A promotion carries every definition in test, from code and from Console alike, to live when a person approves it. Resources match by authoring key.
- Code reaches live through a promotion too. Live refuses code sent to it directly, so your developer always publishes to test first.
- App login keys belong to one environment. A hosted app's staging and preview addresses sign members in to test and its live address to live, so a key for one of those addresses is created only in the environment that address serves. A key for your own app's local address, such as
http://localhost:3000, is a Test key only: develop on localhost against Test, and give the live app an HTTPS address. A promotion never copies keys.
When live refuses a change
In live, Console shows editors for definitions as read-only, with the note "Live changes only through a promotion from test." Choose Edit in Test to open the same page in test, and Promote to live when you're ready. Day-to-day controls stay available.
Trying the same change again in live never works. Make it in test, then promote test to live.
{
"error": "Definitions change in test and reach live through a promotion. Make this change in the test environment.",
"code": "promotion-required"
}