Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

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.

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.

Pre-Deploy

Pre-deploy - 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. 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.

The Pre-deploy workflow inputs flow into the Deploy workflow inputs. For this to work, workflow developers must use the same name and data type for the Pre-deploy output(with "Return As Output" selected) and Deploy input variables in the respective workflows. 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.

Workflows are built using Plugin Operations like SOA Build, WebLogic Deploy or Unix Shell as well as other constructs like If, Assign, While etc. In most cases out of box plugins are very useful, but when necessary users can use plugins like Shell, Groovy, Ant, Maven etc. to perform specific tasks.

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.

  • No labels