Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.

...

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.

...

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.

...

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.

...