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.
Note that Release Management is not available on all subscriptions - refer to Flowgear Pricing to see which subscriptions support this capability.
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 Promote workflow button in the Workflow Design Pane.
On the bottom of the screen the Workflow Promotion Panel will open up . Click the Promote, then click it again to confirm. Repeat as needed for each Site 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.
Note that you can also promote multiple Workflows from the Workflows Pane by selecting Workflows (click the checkbox icon) and then clicking the Promote button.
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 customize the available Environments?
Yes, you can customize the list from the Site Detail Pane - see Managing Site 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 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.