Versions, staging and production

An Application your alarms and schedules depend on should not change while you are still working on it. Save each change as a new version, try it, and promote it to Production once it works: schedules, event triggers and webhooks always run the Production version.

Which version runs

Started by	Runs
A schedule, an event trigger or a webhook	The version in Production. While nothing is in Production, the newest saved version.
You, with the run button on Build › Applications	The newest saved version. Hover over the button to see which: Run v1.1.0.

Staging is a marker for the version you are testing. It tells your team what is being tried out; it does not decide what runs.

Change an Application safely

1. Save the change as a new version

   Make your change. Then, next to the Application's name, change the version number, for example from 1.0.0 to 1.1.0. The console marks it new version. Say what changed in What changed? and select Save.

   

   Saving without changing the number overwrites the version you opened. If that version is in Production, your alarms run the change at once, so always give a change a new number.

2. Promote it to Staging

   Select Staging in the header. The console shows which version Staging is on now and which it will be on. Select Promote to Staging.

   

3. Try it

   On Build›Applications, the run button starts the newest saved version, here v1.1.0. Run it on a simulated or spare device and follow the run in Build›Executions. Your schedules and alarms keep running the Production version meanwhile.

4. Promote it to Production

   When it works, select Production and promote it. From the next run on, every schedule, event trigger and webhook runs the new version.

The header shows where each channel stands. A check mark means the channel is on the version you have open:

Before you promote, the console points out what is worth a second look, for example that the version was never in Staging, or that the promotion moves a channel back to an older version. None of these stop the promotion.

See every version

The Versions tab lists every saved version with its note, when it was saved and by whom, and which version is in Staging and in Production. Select a version to open it.

To roll back, open the older version and promote it to Production.

When a Skill changes

An Application keeps its own copy of every Skill it uses. In the Application, each Skill either follows latest or is pinned to one version.

• When a Skill it follows is saved, the platform updates the Application's newest version and adds a note to its changelog.
• The Production version is never changed this way. When a Skill it uses has moved on, the editor says so, This version is in Production and still runs older versions of …, and offers Update to Skill v…. That saves the update as a new version, for you to try and promote like any other change.
• A Skill pinned to one version never changes on its own.

Troubleshooting

• An alarm ran an old version. That version is in Production. Promote the new one.
• An alarm ran a change you were still working on. Nothing was in Production, so the newest saved version ran, or you saved over the Production version. Promote a tested version to Production, and save future changes under a new number.
• A schedule shows Needs attention after a promotion. The new Production version needs an input the schedule doesn't pass, or no longer contains the Skill it starts. Edit the schedule.

Next steps