Release Management

Release Management allows developers to control when Workflows are promoted to a different Flowgear Environment. This capability allows enhancements to be made to existing Workflows without disrupting Production use. Combined with Revision Management, it is also possible to roll back to earlier versions of a Workflow when needed.

Enabling Release Management

Release Management is disabled by default. To enable, open → Edit Site Settings. Under Release Management & Version Control, set Release Management Mode to Enabled.

The rest of this article assumes that Release Management has been enabled. Also, although Flowgear supports any number of Environments, this article assumes that the two default Environments (Test and Production) are being used.

Building a Workflow under Release Management

When a Workflow is saved, it will be deployed only to the Test (first) Environment. This means that you can safely work on a design for a Workflow without affecting the revision of the Workflow that is deployed into Production.

Promoting a Workflow to the next Environment

When a Workflow is ready for Production use, click the Promote workflow button in the Workflow Design Pane.

At the bottom of the screen, the Promote Workflow Pane shows all Environments along with the Workflow revision currently deployed into each of those Environments.

Click the Promote button to push a Workflow revision from one Environment to the next.

Common Questions

How do Environments relate to Workflow's invoked via API?

Each Environment is associated with a specific Hostname (this is managed under the Environments section of the Site Detail Pane.

When an API invoke request is received, Flowgear will look at the hostname and resolve that to its corresponding Environment. The Workflow will then be invoked using that Environment.

You can verify the Environment a Workflow was invoked under by viewing the InitialisationXml Property of the Start Node Workflow Log.

How do Workflows and Sub-Workflows behave in the context of Release Management?

When a Workflow invokes a Sub-Workflow, the revision of the Sub-Workflow that is deployed into the active Environment will be used.

Stated another way, when a Workflow is started under the Production Environment, any Sub-Workflow that it invokes will also execute under the Production Environment. This also means that the revision of the Sub-Workflow that is deployed into the Production Environment at that time will be used.

Can I customize the available Environments?

Yes, you can customize the list from the Site Detail Pane - see Site Environments.

What does changing the Environment selection do in the Workflow Design Pane?

By default a Workflow will run under the Test Environment when it is started from the Workflow Design Pane. You can switch to a different Environment by clicking the v caret to the right of the start button.

When you do this, the Workflow revision that is currently deployed into that Environment will be used. This will usually be a different revision to the one that is displayed on the Workflow Canvas and a warning to this effect will be shown.

Why isn't Release Management enabled by default?

Release Management adds some technical and cognitive overhead when reasoning about how Workflows relate to each other so it is opt-in. It is also typically not required for simple integrations or integrations that are only used by a small number of people.