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.

Note that Release Management is not available on all subscriptions - refer to Flowgear Pricing to see which subscriptions support this capability.

Screencast

Enabling Release Management

Release Management is disabled by default. To enable it, set the Release Management option in the Site Detail Pane 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 (either manually when Save is clicked or automatically when a changed Workflow is run), it will now be deployed to the Test Environment only.

For this reason, new Workflows will default to the Test Environment and existing Workflows should be switched to Test Environment manually. You can switch Environments by clicking Settings from the Workflow Design Pane and then clicking the Promotion tab. Additionally, Test Environment Connections should be set for all Connections.

Workflows can now be debugged as usual.

Promoting a Workflow to the next Environment

When a Workflow is ready for Production use, click the Settings button in the Workflow Design Pane (cog icon), then click the Promotion tab. A visualisation is presented of available Environments along with the Workflow Revision currently allocated to that Environment. Click the Promote button to push a revision from an
earlier stage Environment to a later stage environment.



End-users executing the Workflow via the Run Now Pane or enabling a Workflow for Always On, will start or enable a Workflow in Production. Because Workflows are being developed in the Test Environment, end-user use of Workflows is unaffected by the Test Environment.

Common Questions

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

Workflows that have been bound to a RESTful endpoint will be invoked in Production. Specifically, the release that is deployed into the Production Environment will be invoked.

To invoke a different revision of a Workflow (i.e. A revision deployed into a different Environment), use the _profile querystring parameter.

For example, for this endpoint:

GET https://mycompanyapi.flowgear.net/customers/abc001/

Use the following

GET https://mycompanyapi.flowgear.net/customers/abc001/?_profile=Test

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. For example, if Workflow A is running under the Production Environment and calls into Workflow B, the revision of Workflow B that is currently in the Production Environment will be executed.

Can I customise the available Environments?

Yes - please chat with us to request additional Environments

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

Switching Environment (by clicking Settings from the Workflow Design Pane, then clicking the Promotion tab and choosing a different Environment under "Environment for Design Area" causes the revision of the Workflow that is deployed into that Environment to be run and also causes it to use Connections from the chosen Environment.

When Release Management is enabled, this will mean that an older version of a Workflow will be run if the Environment is set to Production. Additionally, Connections belonging to the chosen Environment will be used.

When Release Management is not enabled, changing this setting will only affect which Connections are used.

Why isn't Release Management enabled by default?

Release Management adds some technical overhead and cognitive load 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.

Did this answer your question?