Workflow Definition

The Workflow Definition provides a drag-and-drop interface for constructing build and deploy processes, which can be composed of plugin operations, other sub-workflows, and basic workflow operations such as variable assignments, conditionals, and looping constructs.

Editing the Workflow Definition

A Workflow’s definition consists of one or more Steps that define the logic that should be executed by the Workflow. Steps are added by dragging and dropping Operations from the Palette onto the Canvas .

Open

Available Operations can be broken down into 2 categories:

• Plugin Operations - A Plugin in FlexDeploy is a separately installed extension that allows integrations with other 3rd party tools and services. Each such Plugin can have 1 or more operations, called Plugin Operations, which define specific integration tasks for the associated service or product. Plugin Operations are generally the focal point of the Workflow Definition.

• Workflow Operations - Workflow Operations are a set of bundled operations that provide helpful logic constructs and utilities for developing Workflow. Unlike Plugin Operations, Workflow Operations generally do not integrate with 3rd party tools.

The appendix contains a full detailed list of each Operation available when constructing the Workflow Definition.

Configuring Operations

Once you have dragged an Operation from the Palette onto the Canvas you will be prompted to specify any configuration needed for the Step.

Open

In the above example, we are adding a Raise Fault operation. A few key points of emphasis:

1. Step Name - The Step Name helps identify this Step within the Workflow. It will be shown in both the Canvas and later when viewing Workflow Execution details. The Step Name will default to the Operation Name but it is recommended to change it particularly if you have multiple Steps using the same Operation.

2. Step Configuration - Each Operation will have its specific configuration, in the case of Raise Fault, we need to specify the Fault Name and optionally the Fault Details.

3. Groovy Expressions - The majority of Operation configuration inputs allow defining Literals (plain text) or Groovy Expressions. Switching back and forth between the two can be done via the toggle.

4. Saving your Work - When you are finished providing the necessary configuration for the Step you can click the Save button.

See the appendix for a full breakdown of the Raise Fault Operation and other Workflow Operations.

Workflow Versions

When editing the Workflow Definition you are editing a specific version of the Workflow Definition called Workflow Version. In this particular case, we are editing version 1.2

Each Workflow Version can be one of 2 states:

• Draft - When a Workflow Version is in the Draft state you are still allowed to edit and make changes to the Definition.

• Activated - Once a Workflow Version has been activated it will become read-only. It is impossible to make changes to a Version that has been activated.

Making Copies and Activating Versions

A Workflow Definition must have an *activated version before it can be used. Once activated that Workflow Version will be locked and can no longer be modified.

Saving as a Draft

Before a Workflow Version is activated, you can make as many changes as you would like. To save your changes without activating the version, click the Save Draft button in the toolbar.

Activating the Version

Once you are ready for the Workflow Version to be activated simply click the Activate button in the toolbar.

Making a Copy

If you would like to make changes to a previously activated Workflow Version, simply select that Workflow Version from the dropdown and click the pencil icon to make a copy. This will create a new Workflow Version which can be modified and activated again.

Referencing a draft workflow version

Draft Workflow versions can be used without Activating by leveraging the Workflow Version Override option in the advanced section of the Workflow Request form for FlexDeploy Users with configure project permissions.

Advanced Topics

Using Workflow Inputs

Workflow Inputs, like Workflow Properties, provide a way to add custom properties to your Workflow. The key difference is where the values are provided.

• Workflow Inputs - Values are provided on the Workflow Request form and must be specified during each build and deployment.

• Workflow Properties - Values are provided on the Project Properties or Target Properties.

Whether your custom property is a Workflow Property or Workflow Input should largely depend on how often the value will change. If the value changes frequently then perhaps it makes more sense as a Workflow Input. To add an Input to your Workflow click the Inputs button in the Editor.

This will open a popup where you can manage any existing Inputs as well as add new ones.

The configuration for each Workflow Input is almost identical to Workflow Properties. Workflow Inputs can be accessed anywhere in your Workflow via Groovy. See the Using Groovy page for more information.

Creating Local Variables

Often your Workflow may require additional custom properties that should not be entered on the Workflow Request form (Workflow Inputs) or the consuming Project or Target (Workflow Properties). This is exactly the purpose of Workflow Variables, custom properties/variables that are scoped to the Workflow. Some common examples of Workflow Variables are:

• Loop counters

• Variables to capture plugin outputs to use later in the Workflow

• Saving a complex groovy calculation to a variable that can be used later

To create a Workflow Variable, click the Variables button in the Workflow Editor toolbar.

You will notice significantly less configuration to define a Workflow Variable compared to an Input or Property.

Workflow Variable Fields

Tips and Tricks

Custom Project Versions

Each new build of a Project in FlexDeploy generates a new Project Version identifier that is unique to that Project. For example 1.0.1 or 2.beta.3. The logic determining the Project Version is configured on the Project Branches.

However, if you want to control the Project Version based on the build workflow execution, that can be done by assigning to the Pre-defined Variable FD_BUILD_VERSION in the build workflow. The version can only contain Letters, Numbers, Underscores, Dots, and Dashes.

Before assigning to the Variable it must added to your Workflow Definition:

Open the Variable Editor and click on the Add Pre-defined button. Select FD_BUILD_VERSION and confirm. You should now be able to assign any custom value: