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:
- Add a Workflow
- Deploy Individual Workflow
- Verify Workflow
- Add a Workflow Notification Strategy
- Define Workflow Failure Strategy
- Set Workflow Variables
- Use Steps for Different Workflow Tasks
- Add Phases to a Workflow
- Synchronize Workflows in your Pipeline Using Barrier
- Templatize a Workflow
- Clone a Workflow
- Configure Workflow Using YAML
In this topic, we cover the following concepts:
- Before You Begin
- Workflow Types
- Workflow Variable
- Template a Workflow
- Workflow Phases
- Rollback Steps
- Notification Strategy
- Failure Strategies
- Concurrency Strategy
- Next Steps
Before You Begin
Before learning about workflows, you should have an understanding of the following:
The following table lists the Workflow types available when creating a Workflow.
A Basic deployment selects nodes and installs a service.
A Multi-Service uses one or more phases composed of separate steps.
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.
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.
A Rolling deployment lets you gradually roll out your deployment, enabling and disabling services as necessary.
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.
When you submit, the Workflow display the steps needed to perform depending on the Workflow type you selected.
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.
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
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:
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.
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.
To set up rollback steps, do the following:
- 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:
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.
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.
Read the following topics to build on what you've learned: