Workflows

Updated 1 month ago by Archana Singh

Workflows define the deployment orchestration steps, including how a Service is deployed, verified, rolled back, and more. Some of the common Workflow types are Canary, Blue/Green, and Rolling. An Application might have different deployment orchestration steps for different Environments, each managed in a Workflow.

If you're looking for Workflow How-tos, see the following:

In this topic, we cover the following concepts:

Before You Begin

Before learning about workflows, you should have an understanding of the following:

Workflow Types

If you are new to deployment strategies, read Deployment Concepts and Strategies to learn about common deployment strategies. This will help you understand the deployment strategies Harness Workflows implement.

The following table lists the Workflow types available when creating a Workflow.

Workflow Type

Description

Basic

A Basic deployment selects nodes and installs a service.

See:

Multi-Service

A Multi-Service uses one or more phases composed of separate steps.

Canary

A Canary deployment rolls out a new app version to small sets of users in separate phases, tests and verifies it at each phase, gradually rolling it out to your entire infrastructure.

See:

Build

A Build deployment simply builds and collects artifacts. You can use it as part of a Pipeline that builds the latest artifact and deploys it, or as the first step in a Pipeline that is executed in response to a source update such as a Git push event.

If you use a Build Workflow in a Pipeline, you cannot select an artifact when you deploy the Pipeline. A Build Workflow tells Harness you will be building the artifact for deployment as part of the Pipeline. Harness will use that artifact for the Pipeline deployment.

See Build and Deploy Pipelines Overview and Using Build Workflows in a Pipeline.

Rolling

A Rolling deployment lets you gradually roll out your deployment, enabling and disabling services as necessary.

See:

Blue/Green

In a Blue/Green deployment, network traffic to your service/artifact is routed between two identical environments called blue (staging) and green (production). Both environments run simultaneously, containing different versions or the service/artifact.

See:

When you submit, the Workflow display the steps needed to perform depending on the Workflow type you selected.

Workflow Variables

You can set variables in the Workflow Variables section of your Workflow, and use them in the Workflow step commands and settings. For information on variables and expressions, see Variables and Expressions in Harness and Passing Variables into Workflows and Pipelines from Triggers.

Template a Workflow

You can turn a Workflow into a Workflow template ("templatize it") by using variables for important settings such as Environment, Service, and Infrastructure Definition. When the Workflow is deployed, the user must provide values for the settings you have defined as variables.

When you turn a Workflow into a template, if the Workflow still retains references to the entities it was originally created with (such as a Service), any attempts to delete these entities will result in an error, because the template is still using them. You will need to remove the references from the template before you can delete them.

Workflow Templates and Service Types

The Workflow template only works with Services using the same Deployment and Artifact Type as the Service used to create the Workflow. This applies to Services of Deployment Type Secure Shell (SSH).

For example, let's say you created a Workflow using a Service with the Deployment Type Secure Shell (SSH) and Artifact Type JAR. If you have another Service with the same Deployment Type, but the Artifact Type is WAR, the Workflow template will not show it as an option during deployment.

Templatize Phases in Canary Workflows

For Canary Workflows, you edit the Phase settings and click the [T] next to Service. The [T] was automatically selected for Infrastructure Definition when you clicked the [T] for Environment.

Templatized Workflows in Pipelines

Once you have templatized a Workflow, you can use it in multiple stages of a pipeline.

For example, you can templatize the Environment and Infrastructure Definition of a Workflow, and then use the same Workflow for both the QA and Production stages of a Pipeline. When you add the Workflow to each stage, you simply provide QA and Production-specific values for Environment and Infrastructure Definition variables.

Workflow Variables in QA Stage of Pipeline

Workflow Variables in Production Stage of Pipeline

Workflow Phases

In multi-phase deployments, such as a Canary Deployment, Workflow steps are grouped into phases. Here is a Canary Workflow before the phases and sub-steps are added:

You cannot run a Workflow's phases in parallel. Consider using multiple Workflows.

Barriers

When deploying interdependent services, such as microservices or a large and complicated application, there might be a need to coordinate the timing of the different components' deployments. A common example is the need to verify a group of services only after all the services are deployed successfully.

Harness Workflows address this scenario using barriers. Barriers allow you to synchronize different Workflows in your Pipeline, and control the flow of your deployment systematically.

Barriers have an effect only when two or more Workflows use the same barrier name, and are executed in parallel in a Pipeline. When executed in parallel, both Workflows will cross the barrier at the same time.

If a Workflow fails before reaching its barrier point, the Workflow signals the other Workflows that have the same barrier, and the other Workflows will react as if they failed as well. At that point, each Workflow will act according to its Failure Strategy.

For more information on how to synchronize your Workflows using Barriers, see Synchronize Workflows in your Pipeline Using Barriers.

Rollback Steps

You define the steps of a Workflow rollback in Rollback Steps. Typically you want to rollback failed containers and container orchestration setup. You can also verify that the rollback has restored the last working version of your Service.

For Docker, Kubernetes, AWS CodeDeploy, and Lambda deployments, Harness rolls back the deployment to the state that received the new code. In case of a JAR, WAR, RPM, TAR, ZIP and other deployments, Harness provides default rollback steps (Disable, Stop, Deploy, Enable, Wrap-up). You can add custom commands in cases where you need to customize the rollback procedure.

If you deploy a Workflow and choose the Abort option during the running deployment, the Rollback Steps for the Workflow are not executed. Abort stops the deployment execution without rollback or cleanup. To execute the Rollback Steps, click the Rollback button.

To set up rollback steps, do the following:

  1. In a Workflow, click Rollback Steps to see the default steps. Here is an example of the default rollback steps in a Workflow that deploys a Docker image to a Kubernetes cluster:

Notification Strategy

By default, when a Workflow fails, the Account Administrator is notified. You can specify a notification strategy for a Workflow (or for a Workflow phase in a Canary or Multi-Service Workflow) that sends notifications using different criteria.

Failure Strategies

A Failure Strategy defines how your Workflow handles different failure conditions. For example, if you are deploying a Service to a cluster of 100 nodes, what percentage of connectivity errors would you allow before failing the deployment?

There are two ways to define a failure strategy:

  • The Failure Strategy settings for the entire Workflow.
  • Step-level failure strategy for a Workflow step section.

Concurrency Strategy

You can edit a Workflow's Concurrency Strategy section to override Harness' default Workflow queuing behavior. For details, see Using Concurrency Strategy to Control Queuing.

Next Steps

Read the following topics to build on what you've learned:


How did we do?