A workflow is an orchestration of steps which define a build, deployment, test, or utility process. These steps can be a combination of plugin operations or basic workflow operations such as variable assignment, conditionals, or looping constructs. Workflows are configured on each project which allows the project to perform Build and Deploy operations and in the case of Utility projects allows for the execution of desired commands. The Pre-deploy workflow can be used to perform any review for certain deployments like Terraform, Database, etc. prior to running actual Deploy operations to perform validation before deployment.

Workflows are built using Plugin Operations like SOA Build, WebLogic Deploy or Unix Shell as well as other constructs like If, Assign, While etc. Out-of-the-box plugins for specific technologies will be used to complete most of the complicated tasks in workflows, but when necessary, users can use scripting plugins like Shell, Groovy, Ant, Maven etc. to perform custom tasks.

Types of Workflows

There are 4 main types of workflows that FlexDeploy users will work with.

Build

Build workflows are used for building a project. This is used to get source files from SCM or other sources and creates Artifacts that are deployed to a target environment. They create a new version of the project which can be made into part of a release each time they are executed.

Any workflow outputs that were set in the Build will also be available as workflow variables in the following Pre-Deploy and Deploy workflows for that project version. The variables will not show up in the Workflow UI in the variables page, but will be in the project execution, variables screen and can be used like a variable or property in the pre-deploy and deploy workflows. This means that you can assign a build input to a workflow variable in the build and it will be available to the pre-deploy and deploy without creating a file artifact.

Pre-Deploy

Pre-deploy workflows are used for performing any activity prior to running the Deploy workflow in a target group. At the end of the workflow, you can use the default output variables FD_REVIEW_REQUIRED and FD_REVIEW_GROUP to create a review task(Human Task) and assign it to one or more groups. Certain plugins have the ability to override the value of FD_REVIEW_REQUIRED automatically when used in a Pre-deploy workflow.

Pre-deploy workflows will execute when a deploy request is submitted if the checkbox to run the pre-deploy is selected. The project should have the Pre-deploy workflow selected in the configuration screen. The workflow inputs for Pre-deploy should be setup to match the corresponding Deploy workflow of the project. The deploy workflow's inputs will show on the project deployment and release configuration screen. If they aren't also present in the Pre-deploy workflow, the data will not make it through to the deploy workflow. To learn more about workflow inputs see Creating a Workflow.

Deploy

Deploy workflows are used for deploying versioned artifacts to a target environment. This is usually the place that you will perform Property Replacement. Values that are unique to each environment that you will deploy to are modified at this time so that a build can be reused across all environments.

Utility

Utility workflows are used for executing specific operations on target environment against a specific target group. Utility workflows do not deal with any artifacts or have versions that can be used in a release. Examples for utility workflows include restarting a server, executing scripts, or any job that may need to be run ad hoc. Utility projects will never give a message like the project was already deployed. They are not tied to any project source control settings, and usually they don’t use SCM at all.

Overriding Project Version

If you want to control the project version based on a discovery made during the build workflow execution, then return the FD_BUILD_VERSION output from build workflow. The version can only contain Letters, Numbers, Underscore, Dot and Dash.