Skip to main content

Workflows

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:

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 Workflow types are available when creating a Workflow.

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.

See Set Workflow Variables.

For information on variables and expressions, see Variables and Expressions in Harness and Passing Variables into Workflows and Pipelines from Triggers.

Template a Workflow​

See Templatize 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 PipelineWorkflow 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:

note

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.

Harness performs rollback differently depending on the target platform (deployment type), deployment strategy, and the steps where you can configure how we handle old versions. See Kubernetes Rollback and ECS Rollbacks as examples.

In general, during a successful deployment, Harness deletes all old versions of the deployed service except for the last successfully deployed version. This version is kept for rollback. If rollback occurs, Harness restores the last successful version but not the older versions it deleted.

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.

note

  • 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.

  • For post-production rollback, see Rollback Production Deployments.

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.

See Add a Workflow Notification Strategy.

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.

See Define Workflow Failure Strategy.

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.

Rollback a Running Workflow​

You can rollback a running Workflow from the Deployments page.

To rollback a Production deployment from the Services dashboard, see Rollback Production Deployments.This Rollback option requires the following User Group Account and Application permissions:

  • Account: Manage Applications
  • Application: Rollback Workflow

You can also add the Rollback Workflow Application permission via the GraphQL API:

mutation {  
  updateUserGroupPermissions(input: {  
    clientMutationId: "123"  
    userGroupId: "Gh9IDnVrQOSjckFbk_NJWg"  
    permissions: {  
      appPermissions: {  
        actions:[ROLLBACK_WORKFLOW]  
        permissionType: ALL  
        applications: {  
          filterType: ALL  
        }  
        deployments: {  
          filterTypes: NON_PRODUCTION_ENVIRONMENTS  
        }  
      }  
    }  
  }) {  
    clientMutationId  
  }  
}

Rollback Workflow added if Execute Workflow used Previously​

All User Groups that had the Execute Workflow permission enabled will now have Rollback Workflow enabled, also. You can disable it if needed.

Platform and Workflow Support​

Rollback for running Workflows is currently supported the following platforms and strategies:

  • Kubernetes deployments: Basic, Blue/Green, Canary, Rolling Workflows.
  • SSH deployments: Blue/Green, Canary, and Basic Workflows.
  • PCF (Pivotal Cloud Foundry) deployments: Blue/Green, Canary, and Basic Workflows.
  • WinRM (IIS and .NET) deployments: Blue/Green, Canary, and Basic Workflows.
  • ECS deployments: all Workflow types, and both EC2 and Fargate clusters.
  • AMI/ASG deployments: Blue/Green, Canary, and Basic Workflows.

Harness anticipates expanding this feature to other deployment platforms.

Next Steps​

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