...
Every workflow is designated a Type, with each Type serving a different purpose. In order to To understand Workflow Types appropriately its it is important to understand the Build and Deploy process within FlexDeploy. A diagram representing a typical implementation can be seen below.
...
Workflow Type | Description |
---|---|
Build | The first step in the Build/Deploy model. The Build Workflow most commonly does the following tasks:
|
Deploy | The Deploy Workflow is most commonly the next workflow run. Its duties consist of reading or consuming Artifacts published during the Build Workflow and uploading or deploying those Artifacts to your Deploy Target. An example of this could be taking html/css/javascript bundled during build and uploading to Azure to be served. |
PreDeploy | Prior to running the aforementioned Deploy Workflow, you can optionally run a PreDeploy Workflow. The PreDeploy Workflow can use the Build Artifacts and running any checks prior to the Deploy Workflow executing. Some examples of this could be:
Note: Any inputs required or optional defined in the deploy workflow, must be configured in the pre-deploy workflow. These deploy inputs must be either defined in the inputs or in variables. This will facilitate the inputs given in the deploy request form to be set when the deploy workflow is executed from pre-deploy. |
Test Definition | The last Workflow run is a Workflow testing the previous deployment on the Deploy Target. A common example being running some form REST tests, using something like Postman, to validate the Deployment. |
Utility | Utility Workflows fall outside of the typical Build and Deploy process outlined above. Utility Workflows don’t consume or produce any artifacts and are most commonly used to run adhoc on demand logic on a Target Server. A few examples would be:
Note that Utility Workflows can only be used by a specific Project Classification called |
Other | Lastly, the black sheep of the family, Other Workflows cannot be used by any Project directly. Their only usage is to have common Workflow logic that can be called from the Workflow types listed before. |
...
The Assignstep provides the ability to assign a value to a workflow variable or a property. Property values that are overridden will keep the new value for the rest of the workflow execution.
...
Field | Description |
---|---|
Variable | The variable or property that we are assigning to. |
Expression | The expression (groovy) value that should be assigned. |
Error Handler
The Error Handler step essentially provides a try/catch mechanism for your Workflow Definition. The Step itself provides two “scopes” in which nested Workflow Steps can be used. The first being the Default scope and the second being the On Error scope.
...
Should an error occur while processing Steps defined in the Default Scope 1️⃣ , the Workflow Engine will immediately move to the On Error Scope 2️⃣ and start running Steps. The Error Handler Step provides a few configuration options outlined below:
...
Field | Description | ||
---|---|---|---|
Propagate Error | Determines what action should occur after executing the Steps defined in the On Error Scope
| ||
Error Variable | Once an error occurs it can be useful to get access to the error object in your On Error Scope. Specifying a variable in this input will assign that error object into that variable so it can be accessed.
| ||
Error Message Variable | Identical to Error Variable except it only contains the text of the error instead of the full object. |
If
The If Step is a flow-control operation that allows your Workflow to dictate which Steps should be run depending on conditions.
...
Invoke Plugin provides the ability to invoke Plugin Operations for any installed Plugin in FlexDeploy. Unlike the rest of the Workflow Operations, Invoke Plugin cannot be dragged directly onto the Canvas. Instead, a list of available Plugins and Plugin Operations are shown below the Workflow Operations.
...
In this separate section in the Palette, you can search for any Plugin or Plugin Operation and drag it onto the canvas which will present the applicable configuration for that Plugin Operation.
...
1️⃣ The chosen Plugin and Plugin Operation show shown here, these are populated by default based on the Plugin Operation that was dragged into the canvas and rarely need to be changed.
...
4️⃣ Generally the Endpoint Specification does not need to be touched or modified. However, it can still be good to understand what it is and why its it is present.
Whenever a Workflow executes, it is executing executes on a specific Target which is decided when selecting an Environment and Target Group in the Workflow Request form. The cross-section of an Environment and Target Group is called a Target. The decided Target will have 1 or more Endpoints associated to with it. These Endpoints are the physical machines/servers where this Plugin Execution will ultimately take place.
Having said all of that - we are ready to take a look at the available configuration:
Field | Description |
---|---|
Target Group Override | As mentioned above the Target Group and Target are decided when the Workflow Request form is submitted, should you wish to use a different Target Group, that can be specified here. This will result in a different set of Endpoints being used for Plugin Execution. |
Endpoint Selection | A Target can have multiple Endpoints associated to it. This input allows you to specify which of those Endpoints are considered “candidates” for Plugin Execution. Available options are:
|
Endpoint Execution | Once the list of Endpoint candidates is chosen based on Selection criteria above, we can then decide which of those Endpoints should actually perform Plugin Executions. Available options are:
|
Artifacts Delivery
5️⃣ A Plugin Operation has the ability to can Produce or Consume Artifacts from FlexDeploy’s Artifact Repository.
Most Plugin Operations will default these values, for example, most “Build” operations will have Produces checked, and vice versa with “Deploy” operations and Consumes. There are, however, a few Plugin Operations that are more build/deploy agnostic, such as the Shell Plugin - Execute in our example. Those Plugin Operations have the ability to can either Consume, Produce, or do neither. It largely depends on the purpose of the Shell script and in these cases the options must be selected manually.
...
Note that specifying a User Input on its own does not really accomplish anything, it must be used as part of the Plugin Execution, in our case this means using it in our Shell script.
...
The Invoke Test step provides the ability to invoke a group of tests for the Project executing the Workflow. The Step will take into account any filters present in the Test Automation yaml YAML configuration when determining what tests should be run. Several other configuration inputs can be specified to further refine the tests that should be executed.
...
Field | Description |
---|---|
Test Name | Test Name allows further refinement of the tests considered for execution. Test Name and Test Tag will union the results should both be specified. Allows multiple entries separated by comma. This input is a Groovy Script so be sure to enclose any literal text in quotes. |
Tags | Run specific tests with specific tags in the Test Automation yaml configuration. Test Name and Test Tag will union the results should both be specified. Allows multiple entries separated by comma. This input is a Groovy Script so be sure to enclose any literal text in quotes. |
Test Qualifier | We can configure the Step itself to fail should the test results not meet expectation. The Test Qualifier input determines what those expectations should be. Depending upon the value chosen, Test Qualifier Value may be presented to be filled in. Set to No Qualifier to pass the Step regardless of the results. |
Output Variable | You can optionally assign the result of the Step to an output variable that can be used later in the Workflow. |
Invoke Workflow
The Invoke Workflow Step allows the execution of other Workflows from the current Workflow. This allows common Workflow logic to be isolated and reused where needed.
...
Field | Description |
---|---|
Workflow | This is the Workflow that should be called. While the field allows calling ANY other active Workflow, it doesn’t necessarily mean that you should. Generally its good practice to have your common Workflow logic created with the Workflow type Other. |
Version Override | By Default, the active version of the invoked Workflow will be used when running this Step. You can however choose a specific version with this input. |
Inputs (if any) | If the invoked Workflow has any defined Workflow Inputs, those will show up in this section. |
Raise Fault
Raise Fault is a Step that will throw a custom error during Workflow execution. This can be useful if you are doing some upfront validation or if you recognize the Target or Endpoint state is not as it should be.
...
Field | Description |
---|---|
Fault Name | Fault Name should be a shorthand identifier for the particular fault that was thrown. For example CUSTOMERPREFIX_VALIDATION_FAULT |
Fault Details | Fault Details is a longer form description or message of the failure. |
Run Groovy
The Run Groovy Step provides a blank Groovy script with access to all of the Workflow properties, variables, inputs, and FlexDeploy utility functions. Think of the Run Groovy script as a catch-all that can implement any solution if there is not a specific operation for it.
...
The script is defined at by marker 1️⃣. As you are writing your script you may find the need to create additional Workflow Variables that you would like to use outside of this step, in that case, you can quickly add more with the Add new Workflow Variable shortcut 2️⃣ .
...
The While Step allows repetition of the Steps defined in its “scope” while some condition evaluates to true. The most common example is running the same set of steps n number of times before exiting.
...
In the above example, we have a Workflow Variable called counter
with a default value of 1. The loop condition then says we are going to continue executing while the counter is less than 5.
...