Environments and releases

Every project has at least two environments, production and test. Each is a complete, separate backend for your game: its own players, config, flags, tours, blog, support, staff, sign-in settings and server keys. Services are switched on for the whole project, so every environment has the same ones.

Test for development, production for players

Point development builds, playtests and CI at test. Point the builds you ship to stores at production. Because nothing crosses between them unless you promote it, you can make as many test players as you like, try config changes and break things in test without any player noticing.

Your builds and servers choose an environment through these settings, usually set per build configuration:

The API address is the same for every environment. A server key or a player's token decides which environment a request acts in, so a test server key can never touch production data, whatever it asks for.

If you sign players in with EOS, enable EOS separately in each environment. You can use a different EOS client or deployment for each, and set a deployment id so that tokens from one EOS deployment are refused in the other environment.

Adding environments

An admin can add environments to a project, for example staging for release candidates or qa for an outside test team. How many a project can have, production and test included, is set by your org's plan: three on Free and six on Studio. Making one more than that is refused with quota-exceeded; the console's Usage page shows your plan.

An environment key is 2 to 20 characters: lower-case letters, digits and hyphens, starting with a letter. Its app key is the project key and the environment joined by an underscore (skyforge_staging).

A new environment starts empty: no players, config, flags or keys. The console cannot rename or remove an environment today, so choose names you will keep.

Releasing a change

Make a config change in test, check it there, then promote it to production: the console shows what differs between the two environments and applies the differences you choose in one step.

Open Promote between environments from the project page, or Promote on an environment's Config page. It compares test with production unless you choose two others, in either direction.

What is compared

Rows are matched by what they are, not by their internal ids: a config value by its key, a flag or tour by its name, a product by its SKU. A row made in test arrives in production as that environment's own row.

The blog is content, not config, so each environment keeps its own. Whether a feature flag is switched on belongs to each environment: a promoted flag arrives switched off, and one that already exists keeps its setting. Switch it on in production when you are ready.

Choosing what goes

Differences are grouped by kind (config values, feature flags, products and so on), each marked New, Changed or Removed. Open a row to see every column that differs, as the target has it now and as it would be.

• Every new and changed row is chosen to begin with. Choose a whole kind at once, or row by row.
• A removal (a row only the target has) is never chosen for you. Choose it on its own if you mean to delete it.
• Choosing a row chooses what it needs: a new config category value brings its member and category. Letting a row go lets go of anything that needs it.
• Some rows cannot be promoted, and say why: a row the target keeps its own value for, a product that orders in the target still point at (switch it off instead of removing it), or a row something that stays still uses.

Add a note if you like, then promote. The console says exactly what it will add, change and remove before anything is written.

Safe against changes in between

Promotion applies what you saw, or nothing. If a chosen row changed in either environment after the comparison was read, the promotion is refused, nothing is written, and the console lists the rows that moved. Compare again and choose.

All the chosen rows are written in one transaction, and every promotion is kept in the project's history: who promoted what, from where, and when. Your game and servers read the new values from their next request.

Who can promote

Comparing needs access to both environments, and shows only the kinds of config you may manage in both. Promoting needs, in the target environment, the same permission as changing that kind of config by hand there: Config for config values and categories, Feature flags for flags, Tours for tours and Commerce for products. A role with Config but not Feature flags can promote config values and not flags.