Revisions and releases v2

Flowgear separates a Workflow's editable source history from the revision that each Environment runs.

This lifecycle has four related states:

  • A design is the current content in the Workflow designer and can include unsaved changes.
  • A revision is a saved snapshot in the Site's version-control store.
  • A published revision is a saved revision compiled and deployed for one Environment.
  • Workflow status (Enabled or Disabled) determines whether that Environment can start the published Workflow through its runtime interfaces.

Revision history

Saving a changed Workflow creates a new source revision. You don't need to save every time you run the Workflow, only when meaningful progress has been made. A commit message can optionally be captured when saving.

Environment branches

Each Site Environment maps to a version-control branch. The first (Test) Environment is the only Environment into which the designer can save directly.

When Release Management is enabled, saving the Workflow saves and publishes it only to the first Environment. Use Promote to push it to subsequent Environments.

When Release Management is disabled, saving the Workflow saves and publishes it into all Environments. This is simpler, but it does not provide an independent promotion gate between Test and Production.

Publish state

A branch revision and its published version can differ. For example, a source change made through GitHub can update the branch before Flowgear has published that content. Additionally, if the publish fails because of a design problem with the Workflow, the Workflow will still be saved and the user will be warned that the Workflow has not been published.

The Manage releases view compares the branch revision's FileHash with the latest published artifact:

  • Published means the current branch revision and executable artifact match.
  • Not published means no artifact exists or the latest branch revision differs from it.
  • Unauthorized means you cannot inspect the published state for that Environment.

Publishing can fail after source has been saved or promoted. The source revision remains in history. Correct the compilation or configuration issue, then publish the current branch revision again.

Roll back safely

Rollback creates a new forward-moving revision rather than deleting history:

  1. Open the Test Environment in the Workflow designer.
  2. Open Manage revisions.
  3. Open the earlier revision you want to restore.
  4. Review and Debug it with current Connections, dependencies, and representative inputs.
  5. Save it as a new latest revision with a clear commit message.
  6. Promote that revision through the ordered Environments.
  7. Confirm the published FileHash and Workflow status in each target Environment.

An older Workflow definition can depend on a Node version, Connection, Sub-Workflow contract, or API behavior that has since changed. Compilation and a successful Debug run are therefore required parts of rollback review.

GitHub-backed Sites

For a Site configured with GitHub version control, revision identifiers and commit links refer to GitHub, and Environment branches are GitHub branches. Changes or merges made in GitHub update source history, but a branch revision still needs a matching Flowgear publish before the runtime executes it.

Coordinate direct GitHub changes with Console release checks. Do not assume that a successful merge alone proves the Workflow compiled or that its status permits activation.

See also

See Revision Management Pane, Release Management Pane, Compiled Execution, and Workflow Status.