Harness Key Concepts

Updated 1 month ago by Michael Cretzman

This topic describes the key concepts of Harness and its CD Abstraction Model.

First we'll look at resource and tool integration, and then an example Application to demonstrate how you can model a CD pipeline in Harness.

In this topic:

Resource and Tool Integration

Harness integrates with your resources like cloud platforms and repositories and your tools like Jenkins, Jira, ServiceNow, APMs, logging aggregators, Slack, and so on.

Cloud Providers

Cloud Providers describe your public or private cloud or physical infrastructures, like AWS, GCP, Kubernetes, and so on.


Here are Harness Connectors.

Each type of Connector represents a different one of your resources or tools.

Artifact Servers

Artifact Servers represent the sources of the artifacts that are delivered through your delivery pipeline, such as Jenkins, Bamboo, Nexus, Artifactory, Docker Registry, and Helm Repo.

Verification Providers

Next we have Verification Providers, which represent APMs and logging aggregators like AppDynamics, Prometheus, Datadog, and so on.

Harness integrates with your Verification Providers to automatically test and verify your deployments and live, production services using Harness 24/7 Service Guard.

Harness Continuous Verification is a large topic and is covered in depth in CV Summary and Provider Support and CV Strategies, Tuning, and Best Practices. For now, note that Harness uses machine-learning to analyze data from your tools and gain more insight with each deployment, or for each running service over time, enabling Harness to improve its understanding of anomalies and failures.

Source Repo Providers

Source Repo Providers connect Git repositories to Harness and sync your Harness account and Applications with your repo, enabling you to manage deployments via Git.

You can also use your Git repo for specifications such as Kubernetes manifests, Helm charts, and Terraform scripts.

Collaboration Providers

Collaboration Providers integrate your collaboration services such as Email, Slack, Jira, and ServiceNow.

You can then use them to automatically notify users of deployment events and as channels for Approval steps in your deployment process.

CD Abstraction Model

Now that we've looked at how your resources and tools are integrated into Harness, let's look at how your deployment process is modeled using the Harness CD Abstraction Model.

The Harness CD Abstraction Model uses the components below together to model your software delivery process. As you read about each component, we will mention how they combine to form your model.


The deployment model is represented in Harness Applications.

Applications represent groups of microservices, their deployment pipelines, and all the building blocks for those pipelines.


Services represent your microservices and applications.

You define where the artifacts for those microservices come from, and the container specs, configuration variables, and files for those microservices.

Harness includes Services for all of the common orchestration tools, app managers, and compute services such as ECS, Helm, PCF, Lambda, SSH, IIS, and so on.


Earlier we mentioned how Cloud Providers represent your public or private cloud. But you also need to represent your deployment infrastructures in those clouds, such as Dev, QA, Stage, Production, etc. For this, we use Environments.

Environments represent one or more of your deployment infrastructures, such as Dev, QA, Stage, Production, etc.

Multiple environments are useful when building deployment pipelines. Deploying to a QA Environment first, verifying, and then approving the deployment for the production Environment.

Environments use the Services and Cloud Providers you have already modeled to form distinct Infrastructure Definitions.


Workflows model how your application is deployed, verified, and rolled back, and who gets notified, among other important phases.

Workflows include the Service, Environment, and Service Infrastructure to use for the deployment steps, showing how your model is using the Harness abstraction components together:

There are many different types of Workflows, from Basic and Build to Canary and Blue/Green.

Workflows include Verify Steps. This is where we add Harness Verification Providers and apply Harness Continuous Verification to deployments.


In most software delivery processes, you have a pipeline involving multiple steps. To model your entire release process, Harness uses Pipelines.

Pipelines model a collection of one or more stages, containing Workflows for one or more Services and other deployment and verification steps, such as Approvals.


Triggers automate deployments in response to a variety of conditions, such as Git events, new artifacts, schedules, and the success of other pipelines.

You can execute them with cURL and Webhook commands also.

Triggers model the events that initiate your release processes.

Infrastructure Provisioners

Lastly, we have Infrastructure Provisioners. Infrastructure Provisioners use Infrastructure-as-Code technologies like Terraform, Cloud Formation, or even Shell Scripts for custom provisioners.

You add Infrastructure Provisioners to your Application, and then use them in Workflows to provision on the fly, or to simply run commands like Terraform Apply.


What you've seen is how Harness integrates with your resources and tools, and the Harness CD Abstraction Model.

The model is the foundation of Harness. It helps you to model any kind of software delivery process in minutes.

It allows for flexibility while making best practices easy to follow and poor practices difficult to implement.

Most importantly, it takes away the pain points of deployment and gives you confidence in their management and success.

How did we do?