Page Comparison

Build

The first step in the Build/Deploy model. The Build Workflow most commonly does the following tasks:

1. Clones the source code defined on the Project

2. Does some form of compilation on the source code

3. Publishes or produces the results to FlexDeploy’s Artifact Repository.

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:

• Running the deploy in preview mode

• Performing some sanitation logic on the Deploy Target to ensure its ready for Deployment

• Creating a manual task that must be reviewed prior to the Deploy executing

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:

• Restarting a server

• Running a script on a server

• Performing server cleanup on a fixed schedule

Note that Utility Workflows can only be used by a specific Project Classification called Utility or can be referenced from other Workflows.

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.