> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-delivery/troubleshooting-and-resources/resources/new-user/onboarding-path.md).
# 1. Harness Deployments Onboarding Path
This guide explains the five-phase journey for onboarding with Harness CD, from initial account setup to production-ready deployment automation with SSO and infrastructure-as-code. Each phase builds upon the last, introducing key Harness concepts, deployment patterns, governance controls, and automation strategies.
Following this roadmap reduces ramp-up time, ensures best practices are adopted early, and provides a structured path from simple deployments to advanced enterprise patterns. If you are looking for hands-on tutorials rather than a conceptual roadmap, go to [Continuous Delivery tutorials](/continuous-delivery/troubleshooting-and-resources/tutorials/cd-gitops-tutorials.md).
***
### What you will learn
* **Five-phase onboarding journey:** The stages from initial account setup to SSO-enabled DevOps with IaC, and what to accomplish in each phase
* **Key Harness entities:** Services, environments, infrastructure definitions, connectors, delegates, and how they work together
* **Deployment strategies:** When to use rolling, blue-green, canary, and basic deployment patterns for different risk profiles
* **Governance and security:** RBAC models (Center of Excellence vs Distributed DevOps), OPA policy enforcement, and approval workflows
* **Automation patterns:** Templatization for reusable pipelines and Terraform provider for infrastructure-as-code onboarding
***
### Before you begin
This guide assumes:
* Basic understanding of CI/CD concepts and deployment pipelines
* Familiarity with at least one deployment target (Kubernetes, ECS, VMs, serverless, or cloud platforms)
* Access to a Harness account (trial or licensed)
If you prefer hands-on tutorials, go to [Continuous Delivery tutorials](/continuous-delivery/troubleshooting-and-resources/tutorials/cd-gitops-tutorials.md).
***
### Overview
This section lists the major onboarding phases and provides links to more details.
{% hint style="info" %}
Steps marked with an asterisk **(\*)** in the tables below include YAML examples to illustrate configuration. These examples are templates, replace placeholder values (connector references, namespaces, identifiers) with your actual Harness resource names before use.
{% endhint %}
#### [Phase 1: Initial setup](#phase-1-initial-setup)
| **Step** | **Details** | **Documentation Link** | **Demo Video** |
| -------------------------------------------------------------------------------------- | -------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------- |
| [Account and entities setup](#step-1-account--entities-setup) | Create organization, project, invite initial users | [Create organizations and projects](/harness-ai/new-to-harness-platform/get-started.md) | |
| [Delegate installation](#step-2-delegate-installation) | Kubernetes, Docker | [Install Harness Delegate on Kubernetes or Docker](/harness-ai/troubleshooting-and-resources/tutorials/install-delegate.md) | [Watch Video](https://youtu.be/yLMCxs3onH8) |
| [Secret managers and migrating secrets](#step-3-secret-managers-and-migrating-secrets) | AWS KMS, HashiCorp, Azure Key Vault, Google KMS | [Add a secret manager](/harness-ai/troubleshooting-and-resources/tutorials/add-secrets-manager.md) | |
#### [Phase 2: Deploy to QA](#phase-2-deploy-to-qa)
| **Step** | **Details** | **Documentation Link** | **Demo Video** |
| --------------------------------------------------------- | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- |
| [Service Definition and Variables](#services) \* | Runtime Inputs or expressions | [Create services](/continuous-delivery/use-continuous-delivery/cd-building-blocks/services/create-services.md) | [Watch Video](https://youtu.be/02RIvOGd0zg?si=HnK4wHaxLUWEkoFK) |
| [Environments](#environments) \* | Service Override | [Create environments](/continuous-delivery/use-continuous-delivery/cd-building-blocks/environments/create-environments.md) | [Watch Video](https://youtu.be/02RIvOGd0zg?si=HnK4wHaxLUWEkoFK) |
| [Adding artifact sources](#step-2-adding-artifact-source) | Docker Registry, GCR, GCS, ACR, Azure DevOps Artifacts, ECR, etc. | [CD artifact sources](/continuous-delivery/use-continuous-delivery/cd-building-blocks/services/artifact-sources.md) | |
| [Simple pipelines](#step-3-simple-pipeline) \* | Stage, service, environment, infrastructure | [CD pipeline modeling overview](/continuous-delivery/troubleshooting-and-resources/resources/new-user/cd-pipeline-modeling-overview.md) | [Watch Video](https://youtu.be/k-f1nbgGkww?si=_EW6Lcr1qxzrQNVM) |
#### [Phase 3: Deploy to staging](#phase-3-deploy-to-staging)
| **Step** | **Details** | **Documentation Link** | **Demo Video** |
| ---------------------------------------------------------- | ---------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- |
| [Deployment strategies](#step-1-deployment-strategy) \* | Rollback, Blue Green, Canary, Kubernetes Apply, Kubernetes Scale | [Deployment concepts and strategies](/continuous-delivery/use-continuous-delivery/manage-deployments/deployment-concepts.md) | [Watch Video](https://youtu.be/VJjDbwoxLfM?feature=shared) |
| [Triggers and input sets](#step-2-triggers--input-sets) \* | SCM triggers, artifact triggers | [Pipeline triggers](/harness-ai/use-harness-platform/triggers/tutorial-cd-trigger.md) | [Watch Video](https://youtu.be/nIPjsANiKRk?si=euQzhaYGfnPaacUe) |
#### [Phase 4: Deploy to production](#phase-4-deploy-to-production)
| **Step** | **Details** | **Documentation Link** | **Demo Video** |
| ---------------------------------------------------------------------- | --------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- |
| [Approvals and governance (OPA)](#step-1-approvals--governance-opa) \* | Harness Approval, JIRA Approval | [Approvals](/harness-ai/use-harness-platform/approvals/approvals-tutorial.md) | [Watch Video](https://youtu.be/KtE6f5-QHrI?si=zYhrXnedmf2j0bUi) |
| [RBAC](#step-2-rbac) | CoE, Distributed Center of DevOps | [Role-based access control (RBAC) in Harness](/harness-ai/use-harness-platform/platform-access-control.md) | [Watch Video](https://youtu.be/vIQfpRrES44?si=Du5OAej2t2Phu7Hg) |
| [Continuous Verification](#step-3-continuous-verification) | Auto, Rolling Update, Canary, Blue Green, Load Test | [Harness Continuous Verification (CV) overview](/continuous-delivery/use-continuous-delivery/verify-deployments/verify-deployments-with-the-verify-step.md) | |
#### [Phase 5: SSO-enabled DevOps with Infrastructure as Code (IaC)](#phase-5-sso-enabled-devops-with-infrastructure-as-code-iac)
| **Step** | **Details** | **Documentation Link** | **Demo Video** |
| ---------------------------------------------------------------------- | ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- |
| [SSO](#step-1-sso) | SAML SSO with Harness, Okta, OneLogin, Keycloak, etc | [Single Sign-On (SSO) with SAML](/harness-ai/use-harness-platform/authentication/single-sign-on-saml.md) | |
| [Templatization and automation](#step-2-templatization--automation) \* | Templates, Terraform Automation | [Templates overview](/harness-ai/use-harness-platform/templates/template.md) | [Watch Video](https://youtu.be/U-n3VK_RoQc?si=dfokJq6pa6017mqX) |
***
### Phase 1: Initial setup
#### Step 1. Account and entities setup
Harness organizations (orgs) allow you to group projects that share the same goal. For example, all projects for a business unit or division.
A Harness project is a group of Harness modules and their pipelines. For example, a project might have a Harness CI pipeline to build code and push an image to a repo and a Harness CD pipeline to pull and deploy that image to a cloud platform.
**Create a Harness org**
1. In Harness, in **Account Settings**, select **Organizations**.
2. Select **New Organization**. The new organization settings appear.
3. In **Name**, enter a name for your organization.
4. Select **Save and Continue**.
**Invite collaborators**
1. In **Invite People to Collaborate**, enter a user's name and select it.
2. In **Role**, select the role the member will have in this org, such as **Organization Admin** or **Organization Member**.
3. Select **Add**.
* Members receive invites via their email addresses.
* You can always invite more members from within the org later.
4. Select **Finish**. The org is added to the list in **Account Settings** > **Organizations**.
**Create a project**
1. In Harness, go to **Home** and select **Projects**.
2. Select **Project**.
3. Name the project, and select a color. The Id of the project is generated automatically.
4. In **Organization**, select the org you created.
5. Add a description and tags, and then select **Save and Continue**.
6. In **Invite Collaborators**, type a member's name and select it.
7. Select a role for the member, and select **Add**.
8. Select **Save and Continue** to create the project.
#### Step 2. Delegate installation
The Harness Delegate is a service you run in your local network or VPC to connect your artifacts, infrastructure, collaboration, verification, and other providers with Harness Manager.
When you first connect Harness to a third-party resource, the Harness Delegate is installed in your target infrastructure (for example, a Kubernetes cluster). After the delegate is installed and registers with Harness, Harness can connect to third-party resources. The delegate performs all operations, including deployment and integration.
Go to [Install Harness Delegate on Kubernetes or Docker](/harness-ai/troubleshooting-and-resources/tutorials/install-delegate.md) to install the delegate in your target infrastructure.
#### Step 3. Secret managers and migrating secrets
Harness includes a built-in secret management feature that enables you to store encrypted secrets, such as access keys, and use them in your Harness connectors and pipelines. Go to [Add a secret manager](/harness-ai/troubleshooting-and-resources/tutorials/add-secrets-manager.md) to configure a secret manager.
Looking for specific secret managers? Go to:
* [Add an AWS KMS Secret Manager](/harness-ai/use-harness-platform/secrets/secrets-management/add-an-aws-kms-secrets-manager.md)
* [Add a HashiCorp Vault Secret Manager](/harness-ai/use-harness-platform/secrets/secrets-management/add-hashicorp-vault.md)
* [Add an Azure Key Vault Secret Manager](/harness-ai/use-harness-platform/secrets/secrets-management/azure-key-vault.md)
* [Add Google KMS as a Harness Secret Manager](/harness-ai/use-harness-platform/secrets/secrets-management/add-google-kms-secrets-manager.md)
* [Add an AWS Secrets Manager](/harness-ai/use-harness-platform/secrets/secrets-management/add-an-aws-secret-manager.md)
**Phase 1 outcome:** You now have a Harness organization and project, a delegate installed in your target infrastructure, and a secret manager configured for secure credential storage. You are ready to define your first service and environment in Phase 2.
***
### Phase 2: Deploy to QA
#### Step 1. Service and environments
**Services**
Services represent your microservices and other workloads. Each service contains a Service Definition that defines your deployment artifacts, manifests or specifications, configuration files, and service-specific variables. Go to [Create a service](/continuous-delivery/use-continuous-delivery/cd-building-blocks/services/create-services.md#create-a-service) to create services.
Services are often configured using runtime inputs or expressions, so you can change service settings for different deployment scenarios at pipeline runtime. Runtime inputs (`<+input>`) prompt the user for values at execution time, while expressions (for example, `<+pipeline.sequenceId>`) dynamically resolve values from pipeline context. Go to [Using services with inputs and expressions](/continuous-delivery/use-continuous-delivery/cd-building-blocks/services/create-services.md) to use runtime inputs and expressions.
The following examples show a Kubernetes service and an ECS Fargate service. Choose the example that matches your deployment platform. Key fields like `connectorRef`, `imagePath`, and `namespace` are placeholders — replace them with your actual connector and infrastructure identifiers.
{% tabs %}
{% tab title="K8s Service" %}
```yaml
service:
name: k8s-svc
identifier: k8ssvc
serviceDefinition:
spec:
release:
name: release-<+INFRA_KEY_SHORT_ID>
manifests:
- manifest:
identifier: Kubernetes
type: K8sManifest
spec:
store:
type: Github
spec:
connectorRef: account.YourGitHubConnector
gitFetchType: Branch
paths:
- content/en/examples/application/nginx-app.yaml
repoName: kubernetes/website
branch: main
skipResourceVersioning: false
artifacts:
primary:
primaryArtifactRef: <+input>
sources:
- spec:
connectorRef: account.YourArtifactConnector
imagePath: bitnami/kafka
tag: <+input>
digest: ""
identifier: artifact
type: DockerRegistry
type: Kubernetes
tags: {}
```
{% endtab %}
{% tab title="ECS Fargate Service" %}
```yaml
service:
name: ecs-service
identifier: ecs_service
orgIdentifier: default
projectIdentifier: ECS Deployment
serviceDefinition:
type: ECS
spec:
manifests:
- manifest:
identifier: serviceDefinition
type: EcsServiceDefinition
spec:
store:
type: Github
spec:
connectorRef: org.YourGitHubConnector
gitFetchType: Branch
paths:
- applications/ecs-fargate-manifests/CreateServiceRequest.yaml
repoName: harness-community/developer-hub-apps
branch: main
- manifest:
identifier: taskDefinition
type: EcsTaskDefinition
spec:
store:
type: Github
spec:
connectorRef: org.YourGitHubConnector
gitFetchType: Branch
paths:
- ECS/BlueGreenNoVariables/RegisterTaskDefinitionRequest.yaml
repoName: harness-community/developer-hub-apps
branch: main
- manifest:
identifier: scalingPolicy
type: EcsScalingPolicyDefinition
spec:
store:
type: Github
spec:
connectorRef: org.GitHubConnector
gitFetchType: Branch
paths:
- applications/ecs-fargate-manifests/PutScalingPolicyRequest.yaml
repoName: harness-community/developer-hub-apps
branch: main
- manifest:
identifier: scalabletarget
type: EcsScalableTargetDefinition
spec:
store:
type: Github
spec:
connectorRef: org.GitHubConnector
gitFetchType: Branch
paths:
- applications/ecs-fargate-manifests/RegisterScalableTargetRequest.yaml
repoName: harness-community/developer-hub-apps
branch: main
artifacts:
primary:
primaryArtifactRef: <+input>
sources:
- spec:
connectorRef: org.YourAwsConnector
imagePath: your-image-path
tag: latest
region: us-east-1
identifier: ECRartifact
type: Ecr
gitOpsEnabled: false
```
{% endtab %}
{% endtabs %}
**Environments**
Environments represent your deployment targets (QA, Prod, etc). Each environment contains one or more Infrastructure Definitions that list your target clusters, hosts, namespaces, and other infrastructure details. Go to [Create environments](/continuous-delivery/use-continuous-delivery/cd-building-blocks/environments/create-environments.md) to create environments.
{% tabs %}
{% tab title="Environment Definition" %}
```yaml
environment:
name: Env_1
identifier: Env_1
tags: {}
type: Production
orgIdentifier: default
projectIdentifier: Default_Project
variables: []
```
{% endtab %}
{% tab title="Infrastructure Definition" %}
```yaml
infrastructureDefinition:
name: Infra_1
identifier: Infra_1
orgIdentifier: default
projectIdentifier: Default_Project
environmentRef: Env_1
deploymentType: Kubernetes
type: KubernetesDirect
spec:
connectorRef: org.KubernetesConnectorForAutomationTest
namespace: cdp-k8s-qa-sanity
releaseName: release-<+INFRA_KEY_SHORT_ID>
allowSimultaneousDeployments: true
```
{% endtab %}
{% endtabs %}
**Service Overrides**
In DevOps, it is common to have multiple environments, such as development, testing, staging, and production. Each environment might require different configurations or settings for the same service.
For example, in the development environment, a service may need to use a local database for testing, while in the production environment, it should use a high-availability database cluster.
To enable the same service to use different environment settings, DevOps teams can override service settings for each environment.
Go to [Create service overrides](/continuous-delivery/use-continuous-delivery/cd-building-blocks/environments/create-environments.md#create-service-overrides) to configure environment-specific service settings.
#### Step 2. Adding artifact sources
In DevOps, an artifact source is a location where the compiled, tested, and ready-to-deploy software artifacts are stored. These artifacts could be container images, compiled binary files, executables, or any other software components that are part of the application.
To add an artifact source, you add a Harness connector to the artifact platform (DockerHub, GCR, Artifactory, etc.) and then add an artifact source to a Harness service that defines the artifact source name, path, tags, and so on.
For the list of artifact sources that you can use in your Harness services, go to [Artifact Sources](/continuous-delivery/use-continuous-delivery/cd-building-blocks/services/artifact-sources.md).
#### Step 3. Create a simple pipeline
To create a simple CD pipeline:
1. Create a pipeline.
2. Add a CD stage.
3. Define a service.
4. Target an environment and infrastructure.
5. Select execution steps.
You can model pipelines visually in the UI, using YAML, or via the REST API.
{% embed url="" %}
The following example shows a simple CD pipeline using a Kubernetes rolling deployment. Replace placeholder values like `Service_1`, `Env_1`, and `Infra_1` with your actual service, environment, and infrastructure identifiers.
K8s Rolling Deployment Pipeline YAML
```yaml
pipeline:
name: K8s Rolling Deployment
identifier: K8s_Rolling_Deployment
projectIdentifier: Default Project
orgIdentifier: default
tags: {}
stages:
- stage:
name: Rolling Deployment
identifier: Rolling_Deployment
description: ""
type: Deployment
spec:
deploymentType: Kubernetes
service:
serviceRef: Service_1
serviceInputs:
serviceDefinition:
type: Kubernetes
spec:
artifacts:
primary:
primaryArtifactRef: <+input>
sources: <+input>
environment:
environmentRef: Env_1
deployToAll: false
infrastructureDefinitions:
- identifier: Infra_1
execution:
steps:
- step:
name: Rolling Deployment
identifier: rolloutDeployment
type: K8sRollingDeploy
timeout: 10m
spec:
skipDryRun: false
pruningEnabled: false
rollbackSteps:
- step:
name: Rollback Rollout Deployment
identifier: rollbackRolloutDeployment
type: K8sRollingRollback
timeout: 10m
spec:
pruningEnabled: false
tags: {}
failureStrategies:
- onFailure:
errors:
- AllErrors
action:
type: StageRollback
```
**Phase 2 outcome:** You have created a service with artifact sources, an environment with infrastructure definitions, and executed your first simple pipeline to deploy to QA. You are now ready to adopt advanced deployment strategies in Phase 3.
***
### Phase 3: Deploy to staging
#### Step 1. Deployment strategies
You have likely heard terms like blue/green and canary when it comes to deploying code and applications into production. These are common deployment strategies, available in Harness CD as stage strategies, along with others.
{% embed url="" %}
Harness supports multiple deployment strategies. Choose based on your risk tolerance and rollback needs:
* **Rolling:** Incremental updates with gradual instance replacement (default for most use cases)
* **Blue Green:** Deploy new version alongside old, then instant traffic switch (instant rollback capability)
* **Canary:** Gradual traffic shift to new version with validation between phases (detect issues early before full rollout)
* **Basic Deployments (Apply):** Declarative Kubernetes resource application (for static configs like namespaces, ConfigMaps)
* **Multi-service:** Deploy multiple services in a single stage
The following YAML examples illustrate each strategy. Replace placeholder values like `Service_1`, `Env_1`, and connector references with your actual Harness identifiers.
{% tabs %}
{% tab title="Rolling" %}
```yaml
pipeline:
name: K8s Rolling Deployment
identifier: K8s_Rolling_Deployment
projectIdentifier: Default Project
orgIdentifier: default
tags: {}
stages:
- stage:
name: Rolling Deployment
identifier: Rolling_Deployment
description: ""
type: Deployment
spec:
deploymentType: Kubernetes
service:
serviceRef: Service_1
serviceInputs:
serviceDefinition:
type: Kubernetes
spec:
artifacts:
primary:
primaryArtifactRef: <+input>
sources: <+input>
environment:
environmentRef: Env_1
deployToAll: false
infrastructureDefinitions:
- identifier: Infra_1
execution:
steps:
- step:
name: Rolling Deployment
identifier: rolloutDeployment
type: K8sRollingDeploy
timeout: 10m
spec:
skipDryRun: false
pruningEnabled: false
rollbackSteps:
- step:
name: Rollback Rollout Deployment
identifier: rollbackRolloutDeployment
type: K8sRollingRollback
timeout: 10m
spec:
pruningEnabled: false
tags: {}
failureStrategies:
- onFailure:
errors:
- AllErrors
action:
type: StageRollback
```
{% endtab %}
{% tab title="Blue Green" %}
```yaml
pipeline:
name: K8s Blue Green Deployment
identifier: K8s_Blue_Green_Deployment
projectIdentifier: Default Project
orgIdentifier: default
tags: {}
stages:
- stage:
name: Blue Green Deployment
identifier: Blue_Green_Deployment
description: ""
type: Deployment
spec:
deploymentType: Kubernetes
service:
serviceRef: Service_1
serviceInputs:
serviceDefinition:
type: Kubernetes
spec:
artifacts:
primary:
primaryArtifactRef: <+input>
sources: <+input>
environment:
environmentRef: Env_1
deployToAll: false
infrastructureDefinitions:
- identifier: Infra_1
execution:
steps:
- step:
name: Stage Deployment
identifier: stageDeployment
type: K8sBlueGreenDeploy
timeout: 10m
spec:
skipDryRun: false
pruningEnabled: false
- step:
name: Swap primary with stage service
identifier: bgSwapServices
type: K8sBGSwapServices
timeout: 10m
spec:
skipDryRun: false
rollbackSteps:
- step:
name: Swap primary with stage service
identifier: rollbackBgSwapServices
type: K8sBGSwapServices
timeout: 10m
spec:
skipDryRun: false
tags: {}
failureStrategies:
- onFailure:
errors:
- AllErrors
action:
type: StageRollback
timeout: 10m
variables:
- name: resourceNamePrefix
type: String
description: ""
required: false
value: cdpsanitysuites-trybg
```
{% endtab %}
{% tab title="Canary" %}
```yaml
pipeline:
name: K8s Canary Deployment
identifier: K8s_Canary_Deployment
projectIdentifier: Default Project
orgIdentifier: default
tags: {}
stages:
- stage:
name: Canary Deployment
identifier: Canary_Deployment
description: ""
type: Deployment
spec:
deploymentType: Kubernetes
service:
serviceRef: Service_1
serviceInputs:
serviceDefinition:
type: Kubernetes
spec:
artifacts:
primary:
primaryArtifactRef: <+input>
sources: <+input>
environment:
environmentRef: Env_1
deployToAll: false
infrastructureDefinitions:
- identifier: Infra_1
execution:
steps:
- stepGroup:
name: Canary Deployment
identifier: canaryDepoyment
steps:
- step:
name: Canary Deployment
identifier: canaryDeployment
type: K8sCanaryDeploy
timeout: 10m
spec:
instanceSelection:
type: Count
spec:
count: 1
skipDryRun: false
- step:
name: Canary Delete
identifier: canaryDelete
type: K8sCanaryDelete
timeout: 10m
spec: {}
- stepGroup:
name: Primary Deployment
identifier: primaryDepoyment
steps:
- step:
name: Rolling Deployment
identifier: rollingDeployment
type: K8sRollingDeploy
timeout: 10m
spec:
skipDryRun: false
rollbackSteps:
- step:
name: Canary Delete
identifier: rollbackCanaryDelete
type: K8sCanaryDelete
timeout: 10m
spec: {}
- step:
name: Rolling Rollback
identifier: rollingRollback
type: K8sRollingRollback
timeout: 10m
spec: {}
tags: {}
failureStrategies:
- onFailure:
errors:
- AllErrors
action:
type: StageRollback
variables:
- name: resourceNamePrefix
type: String
description: ""
required: false
value: cdpsanitysuites-trycanary
timeout: 10m
```
{% endtab %}
{% tab title="K8s with Apply" %}
```yaml
pipeline:
name: K8s Deployment with Apply Step
identifier: K8s_Deployment_with_Apply_Step
projectIdentifier: Default Project
orgIdentifier: default
tags: {}
stages:
- stage:
name: Deployment with Apply Step
identifier: Deployment_with_Apply_Step
description: ""
type: Deployment
spec:
deploymentType: Kubernetes
service:
serviceRef: Service_1
serviceInputs:
serviceDefinition:
type: Kubernetes
spec:
artifacts:
primary:
primaryArtifactRef: <+input>
sources: <+input>
environment:
environmentRef: Env_1
deployToAll: false
infrastructureDefinitions:
- identifier: Infra_1
execution:
steps:
- step:
type: K8sApply
name: K8s Apply
identifier: K8s_Apply
spec:
filePaths:
- namespace.yaml
- service.yaml
skipDryRun: false
skipSteadyStateCheck: false
skipRendering: false
overrides: []
timeout: 10m
rollbackSteps: []
tags: {}
failureStrategies:
- onFailure:
errors:
- AllErrors
action:
type: StageRollback
timeout: 10m
variables:
- name: resourceNamePrefix
type: String
description: ""
required: false
value: cdpsanitysuites-qwerandom
```
{% endtab %}
{% tab title="K8s with Scale" %}
```yaml
pipeline:
name: K8s Deployment with Scale Step
identifier: K8s_Deployment_with_Scale_Step
projectIdentifier: Default Project
orgIdentifier: default
tags: {}
stages:
- stage:
name: Deployment With Scale Step
identifier: Deployment_With_Scale_Step
description: ""
type: Deployment
spec:
deploymentType: Kubernetes
service:
serviceRef: Service_1
serviceInputs:
serviceDefinition:
type: Kubernetes
spec:
artifacts:
primary:
primaryArtifactRef: <+input>
sources: <+input>
environment:
environmentRef: Env_1
deployToAll: false
infrastructureDefinitions:
- identifier: Infra_1
execution:
steps:
- step:
name: Rollout Deployment
identifier: rolloutDeployment
type: K8sRollingDeploy
timeout: 10m
spec:
skipDryRun: false
pruningEnabled: false
- step:
type: K8sScale
name: K8sScale_1
identifier: K8sScale_1
spec:
workload: Deployment/<+stage.variables.resourceNamePrefix>-deployment
skipSteadyStateCheck: false
instanceSelection:
type: Count
spec:
count: 2
timeout: 10m
rollbackSteps:
- step:
name: Rollback Rollout Deployment
identifier: rollbackRolloutDeployment
type: K8sRollingRollback
timeout: 10m
spec:
pruningEnabled: false
tags: {}
failureStrategies:
- onFailure:
errors:
- AllErrors
action:
type: StageRollback
variables:
- name: resourceNamePrefix
type: String
description: ""
required: false
value: cdpsanitysuites-tryscale
timeout: 10m
```
{% endtab %}
{% endtabs %}
Go to [Deployment concepts and strategies](/continuous-delivery/use-continuous-delivery/manage-deployments/deployment-concepts.md) to learn more about choosing the right strategy for your deployment scenario.
#### Step 2. Triggers and input sets
Triggers automatically initiate pipeline execution based on specific events or conditions, such as Git events, new Helm Charts, new artifacts, or specific time intervals. Triggers in Harness CD enable faster feedback cycles, enhanced efficiency, and decreased reliance on manual intervention during the deployment process.
Here are examples of a new artifact trigger and GitHub Webhook trigger:
{% tabs %}
{% tab title="Trigger On New Artifact" %}
```yaml
trigger:
name: trigger_on_new_artifact_v2
identifier: trigger_on_new_artifact_v2
enabled: true
tags: {}
orgIdentifier: default
projectIdentifier: default_project
pipelineIdentifier: trigger_on_new_artifact
stagesToExecute: []
source:
type: Artifact
spec:
type: DockerRegistry
spec:
connectorRef: account.Pritish_Harness
imagePath: pritishharness/harness_test
tag: <+trigger.artifact.build>
eventConditions: []
inputYaml: |
pipeline:
identifier: trigger_on_new_artifact
stages:
- stage:
identifier: test
type: Deployment
spec:
service:
serviceInputs:
serviceDefinition:
type: Kubernetes
spec:
artifacts:
primary:
sources:
- identifier: artifact
type: DockerRegistry
spec:
tag: <+lastPublished.tag>
```
{% endtab %}
{% tab title="GitHub Webhook Trigger" %}
```yaml
trigger:
name: github_filechange_trigger
identifier: github_filechange_trigger
enabled: true
encryptedWebhookSecretIdentifier: ""
description: ""
tags: {}
orgIdentifier: default
stagesToExecute: []
projectIdentifier: default_project
pipelineIdentifier: github_filechange_trigger
source:
type: Webhook
spec:
type: Github
spec:
type: PullRequest
spec:
connectorRef: account.CIPHERTron
autoAbortPreviousExecutions: false
payloadConditions:
- key: changedFiles
operator: Equals
value: README.md
- key: targetBranch
operator: Equals
value: main
headerConditions: []
repoName: harness-yarn-demo
actions:
- Open
inputYaml: |
pipeline:
identifier: github_filechange_trigger
properties:
ci:
codebase:
build:
type: branch
spec:
branch: <+trigger.branch>
```
{% endtab %}
{% endtabs %}
**Phase 3 outcome:** You have implemented a deployment strategy for staging environments and configured triggers to automate pipeline execution based on Git events or artifact updates. You are ready to add governance and verification before promoting to production in Phase 4.
***
### Phase 4: Deploy to production
#### Step 1. Approvals and governance (OPA)
**Approvals**
* **Harness manual approvals**: You can specify Harness user group(s) to approve or reject a pipeline at any point in its execution. During deployment, the user group members use Harness Manager to approve or reject the pipeline deployment manually.
* **JIRA approvals**: Jira issues can be used to approve or reject a pipeline or stage at any point in its execution. During deployment, the pipeline evaluates the fields in the Jira ticket based on criteria you define. Its approval or rejection determines if the pipeline or stage may proceed. You can add the Jira Approval step in Approval stages or in CD stages. The Jira Approval step prevents the stage execution from proceeding without an approval.
* **ServiceNow approvals**: You can use ServiceNow tickets to approve or reject a pipeline or stage at any point in its execution. During deployment, a ServiceNow ticket's fields are evaluated according to the criteria you define, and its approval or rejection determines if the pipeline or stage may proceed.
* **Custom approvals**: Custom approval stages and steps add control gates to your pipelines by allowing you to approve or reject a pipeline or stage at any point during build execution. When you add a Custom Approval step, you add a script to the step, and then use the script results as approval or rejection criteria.
When an approval step is denied, the pipeline stops execution and logs the denial reason. The pipeline status shows as "Aborted" or "Failed" depending on failure strategy configuration. When approved, the pipeline proceeds to the next step. Approval history is visible in the pipeline execution details.
Go to [Approvals](/continuous-delivery/use-continuous-delivery/cd-building-blocks/cd-steps/approvals.md) to learn more about configuring approvals.
**Governance**
Harness Policy As Code uses Open Policy Agent (OPA) as the central service to store and enforce policies for the different entities and processes across the Harness platform. You can centrally define and store policies and then select where (which entities) and when (which events) they will be applied.
Policies are written in Rego, OPA's policy language. Each policy contains a `deny[msg]` rule that evaluates input data (workspace config, Terraform plan, or state) and returns an error message if the rule fails. Go to [OPA policy language documentation](https://www.openpolicyagent.org/docs/latest/policy-language/) to learn Rego syntax and semantics.
The following examples show Harness governance patterns with OPA.
{% tabs %}
{% tab title="Delegate Tag Governance" %}
```
package pipeline
# Allow pipeline execution only with specific delegate tag selected
deny[msg] {
# Find all pipeline stages
stage := input.pipeline.stages[_].stage
# Find all steps in each stage
step := stage.spec.execution.steps[_].step
# Check if the step has a delegate selector
delegateSelector := step.advanced.delegateSelector
# Check if the delegate selector has the specific tag
not contains(delegateSelector.tags, "specific_tag")
# Show a human-friendly error message
msg := sprintf("Pipeline '%s' cannot be executed without selecting a delegate with tag 'specific_tag'", [input.pipeline.name])
}
```
{% hint style="info" %}
**NOTE**
This policy denies pipeline execution if a step in any stage does not have the specific delegate tag selected in its delegate selector. If the tag is not selected, the policy will show a human-friendly error message.
{% endhint %}
{% endtab %}
{% tab title="Connectors Governance" %}
```
package pipeline
# Deny pipeline execution if a specific connector is not selected
deny[msg] {
# Find all stages ...
stage = input.pipeline.stages[_].stage
# ... that have steps ...
step = stage.spec.execution.steps[_].step
# ... that use a connector ...
connector = step.spec.connectorRef.name
# ... that is not in the allowed list
not contains(allowed_connectors, connector)
# Show a human-friendly error message
msg := sprintf("Pipeline '%s' cannot use connector '%s'", [input.pipeline.name, connector])
}
# Connectors that can be used for pipeline execution
allowed_connectors = ["MyConnector1", "MyConnector2"]
contains(arr, elem) {
arr[_] = elem
}
```
{% hint style="info" %}
**NOTE**
You can customize the `allowed_connectors` list to include the connectors that are allowed for pipeline execution. If a pipeline uses a connector that is not in the `allowed_connectors` list, the policy will deny pipeline execution and display an error message.
{% endhint %}
{% endtab %}
{% tab title="Environment Governance" %}
```
package pipeline
# Deny pipelines that do not use allowed environments
# NOTE: Try removing "test" from the 'allowed_environments' list to see the policy fail
deny[msg] {
# Find all deployment stages
stage = input.pipeline.stages[_].stage
stage.type == "Deployment"
# ... where the environment is not in the allow list
not contains(allowed_environments, stage.spec.infrastructure.environment.identifier)
# Show a human-friendly error message
msg := sprintf("deployment stage '%s' cannot be deployed to environment '%s'", [stage.name, stage.spec.infrastructure.environment.identifier])
}
# Deny pipelines if the environment is missing completely
deny[msg] {
# Find all deployment stages
stage = input.pipeline.stages[_].stage
stage.type == "Deployment"
# ... without an environment
not stage.spec.infrastructure.environment.identifier
# Show a human-friendly error message
msg := sprintf("deployment stage '%s' has no environment identifier", [stage.name])
}
# Environments that can be used for deployment
allowed_environments = ["dev","qa","prod"]
contains(arr, elem) {
arr[_] = elem
}
```
{% hint style="info" %}
**NOTE**
You can modify the `allowed_environments` list to include the environments where you want the pipeline to be executed. If the pipeline is executed in an environment that is not in the `allowed_environments` list, the policy will fail and display an error message.
{% endhint %}
{% endtab %}
{% endtabs %}
**Freeze deployments**
A deployment freeze is a period of time during which no new changes are made to a system or application. This ensures that a system or application remains stable and free of errors, particularly in the lead-up to a major event or release. During a deployment freeze, only critical bug fixes and security patches might be deployed, and all other changes are put on hold until the freeze is lifted. Deployment freezes are commonly used in software development to ensure that a system is not destabilized by the introduction of new code in new application versions.
For more information, go to [Freeze deployments](/continuous-delivery/use-continuous-delivery/manage-deployments/deployment-freeze.md).
Here's a sample YAML to set up deployment freeze in Harness:
```yaml
freeze:
name: test-freeze
identifier: testfreeze
entityConfigs:
- name: project_specific
entities:
- type: Project
filterType: NotEquals
entityRefs:
- chaosprjyps
- CI_QS_yps
- ypsnativehelm
- type: Service
filterType: All
- type: Environment
filterType: All
- type: EnvType
filterType: Equals
entityRefs:
- Production
status: Disabled
orgIdentifier: testOrgyps
windows:
- timeZone: Asia/Calcutta
startTime: 2023-11-18 08:39 PM
duration: 30m
recurrence:
type: Monthly
description: ""
```
#### Step 2. RBAC
To perform Role-based access control (RBAC), a Harness account administrator assigns resource-related permissions to members of Harness user groups.
Choose an RBAC strategy based on your organizational structure:
* **Center of Excellence (CoE):** Centralized control with a dedicated platform team managing Harness resources, connectors, and policies across all projects. Best for organizations that prioritize standardization and governance.
* **Distributed DevOps:** Each project team manages their own Harness resources with account-level admin oversight. Best for organizations with autonomous teams that need flexibility.
The following tables detail permissions and resource groups for each role in both strategies.
Center of excellence RBAC strategy
| Role Type | Role Description | Harness Roles | Harness Resource Groups |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------- | ------------------------------ |
| Program Manager | Responsible for analyzing and reporting various metrics | Shared Resources->Dashboards: View & Manage | Shared Resources -> Dashboards |
| Platform Admin | Responsible for provisioning infrastructure and managing Harness resources like Secrets, Environment, Connectors and Delegates | - Shared Resources -> Secrets: View, Create/Edit, Delete & Access | |
* Shared Resources -> Connectors: View, Create/Edit, Delete & Access
* Shared Resources -> Delegates: View, Create/Edit & Delete
* Shared Resources -> Delegate Configurations: View, Create/Edit & Delete
* Environments: View, Create/Edit, Delete & Access
* Environment Groups: View, Create/Edit, Delete & Access | - Shared Resources -> Secrets
* Shared Resources -> Connectors
* Shared Resources -> Delegates
* Shared Resources -> Delegate Configurations
* Environments
* Environment Groups | | Devops Admin | Responsible for setting up Policies to adhere to certain organizational standards, managing Users and various other things like Default Settings, Auth Settings, etc | Administrative Functions: All permissions Services: View, Create/Edit, Delete & Access Environments: View & Access Environment Groups: View & Access Shared Resources -> Templates: View, Create/Edit, Delete, Access & Copy Shared Resources -> Files: View, Create/Edit, Delete & Access Shared Resources -> Deployment Freeze: Manage, Override & Global Shared Resources -> Secrets: View & Access Shared Resources -> Connectors: View & Access Shared Resources -> Variables: View, Create/Edit & Delete Shared Resources -> Delegates: View Shared Resources -> Delegate Configurations: View Pipelines: View, Create/Edit, Delete & Execute | Administrative Functions: All Resources under it Shared Resources: All Resources under it except Dashboards Services Environments Environment Groups Pipelines | | Devops Engineer | Responsible for managing Services, Templates, Files, Variables, Pipelines, Triggers, Input Sets etc. | Services: View, Create/Edit & Access Environments: View & Access Environment Groups: View & Access Shared Resources -> Templates: View, Create/Edit, Access & Copy Shared Resources -> Secrets: View & Access Shared Resources -> Connectors: View & Access Shared Resources -> Variables: View & Create/Edit Shared Resources -> Files: View & Create/Edit Pipelines: View, Create/Edit & Execute | Shared Resources: All Resources under it except Dashboards Services Environments Environment Groups Pipelines |
Distributed DevOps strategy
| Role Type | Role Description | Harness Roles | Harness Resource Groups | Resource Scope |
| ----------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- | ------------------------------------------------ | ---------------------------------------------- |
| Harness Admin | Responsible for managing Users and various other things like Default Settings, Auth Settings, etc | Administrative Functions: All permissions | Administrative Functions: All Resources under it | All (including all Organizations and Projects) |
| Project DevOps Admin | Responsible for provisioning infrastructure and managing Harness resources like Secrets, Environment, Connectors and Delegates, setting up Policies to adhere to certain organizational standards and keeping an eye on all the entities of an Organization within Harness Platform | Services: View, Create/Edit, Delete & Access | | |
| Shared Resources -> Templates: View, Create/Edit, Delete, Access & Copy | | | | |
| Shared Resources -> Files: View, Create/Edit, Delete & Access | | | | |
| Shared Resources -> Deployment Freeze: Manage, Override & Global | | | | |
| Shared Resources -> Secrets: View, Create/Edit, Delete & Access | | | | |
| Shared Resources -> Connectors: View, Create/Edit, Delete & Access | | | | |
| Shared Resources -> Delegates: View, Create/Edit & Delete | | | | |
| Shared Resources -> Delegate Configurations: View, Create/Edit & Delete | | | | |
| Environments: View, Create/Edit, Delete & Access | | | | |
| Environment Groups: View, Create/Edit, Delete & Access | | | | |
| Shared Resources -> Variables: View, Create/Edit & Delete | | | | |
| Pipelines: View, Create/Edit, Delete & Execute | | | | |
| Shared Resources -> Dashboards: View & Manage | Shared Resources | | | |
| Services | | | | |
| Environments | | | | |
| Environment Groups | | | | |
| Pipelines | Specified Organizations (and their Projects) | | | |
| Project DevOps Engineer | Responsible for managing Services, Templates, Files, Variables, Pipelines, Triggers, Input Sets etc. of an Organization within Harness Platform | Services: View, Create/Edit & Access | | |
| Shared Resources -> Templates: View, Create/Edit, Access & Copy | | | | |
| Shared Resources -> Secrets: View & Access | | | | |
| Shared Resources -> Connectors: View & Access | | | | |
| Shared Resources -> Variables: View & Create/Edit | | | | |
| Shared Resources -> Files: View & Create/Edit | | | | |
| Environments: View & Access | | | | |
| Environment Groups: View & Access | | | | |
| Pipelines: View, Create/Edit & Execute | | | | |
| Shared Resources -> Dashboards: View | Shared Resources | | | |
| Services | | | | |
| Environments | | | | |
| Environment Groups | | | | |
| Pipelines | Specified Organizations (and their Projects) | | | |
{% tabs %}
{% tab title="Center of Excellence" %}
{% tabs %}
{% tab title="Program Manager" %}
**Roles** 
**Resource Groups** 
{% endtab %}
{% tab title="Platform Admin" %}
**Roles**   
**Resource Groups** 
{% endtab %}
{% tab title="DevOps Admin" %}
**Roles**    
**Resource Groups**  
{% endtab %}
{% tab title="DevOps Engineer" %}
**Roles**   
**Resource Groups**  
{% endtab %}
{% endtabs %}
{% endtab %}
{% tab title="Distruibuted DevOps" %}
{% tabs %}
{% tab title="Harness Admin" %}
**Roles** 
**Resource Groups** 
{% endtab %}
{% tab title="Project DevOps Admin" %}
**Roles**  
**Resource Groups**  
{% endtab %}
{% tab title="Project DevOps Engineer" %}
**Roles**   
**Resource Groups**  
{% endtab %}
{% endtabs %}
{% endtab %}
{% endtabs %}
Go to [Role-based access control (RBAC) in Harness](/harness-ai/use-harness-platform/platform-access-control.md) to configure RBAC in Harness.
#### Step 3. Continuous Verification
Harness Continuous Verification (CV) is a critical tool in the deployment pipeline that validates deployments by integrating with APMs and logging tools to verify that the deployment is running safely and efficiently.
Harness CV applies machine learning algorithms to every deployment for identifying normal behavior. This allows Harness to identify and flag anomalies in future deployments. During the **Verify** step, Harness CV automatically triggers a rollback if anomalies are found.
**Deployment strategies for Continuous Verification**:
* Continuous Verification type
* Auto
* Rolling Update
* Canary
* Blue Green
* Load Test
* Sensitivity
* Duration
* Artifact tag
* Fail on no analysis
* Health Source
During the Verify step, Harness compares deployment metrics (error rates, latency, throughput) against a learned baseline from previous deployments. If metrics deviate beyond the sensitivity threshold (Low/Medium/High), Harness flags an anomaly. When "Fail on no analysis" is enabled, the pipeline rolls back automatically. View anomaly detection results and metric comparisons in the Verify step logs within the pipeline execution.
Go to [Configure CV](/continuous-delivery/use-continuous-delivery/verify-deployments/configure-cv.md) to configure continuous verification.
**Phase 4 outcome:** You have production-ready pipelines with approval gates, policy enforcement, RBAC configured for your team structure, and continuous verification to detect and roll back failed deployments. You are ready to scale onboarding and automation with SSO and infrastructure-as-code in Phase 5.
***
### Phase 5: SSO-enabled DevOps with Infrastructure as Code (IaC)
#### Step 1. SSO
Harness supports Single Sign-On (SSO) with SAML, integrating with your SAML SSO provider to enable you to log your users into Harness as part of your SSO infrastructure. The user can choose between a variety of SSO integrations according to their needs.
Go to [Authentication](/harness-ai/use-harness-platform/authentication.md) to configure SSO.
#### Step 2. Templatization & Automation
**Templatization**
Harness enables you to add templates to create reusable logic and Harness entities (like steps, stages, and pipelines) in your pipelines. You can link templates in your pipelines or share them with your teams for improved efficiency.
Templates enhance developer productivity, reduce onboarding time, and enforce standardization across the teams that use Harness. Here's an example template that builds a JavaScript application, runs unit tests and pushes to docker registry.
Sample Golden Deployment Pipeline Template
```yaml
template:
name: Golden Deploy
identifier: Golden_Deploy
type: Stage
projectIdentifier: Platform_Demo
orgIdentifier: default
spec:
type: Deployment
spec:
serviceConfig:
serviceDefinition:
type: Kubernetes
spec:
artifacts:
sidecars: []
primary:
type: Gcr
spec:
connectorRef: TestGCP_inherit
imagePath: sales-209522/platform-demo
registryHostname: us.gcr.io
tag: <+pipeline.sequenceId>
manifestOverrideSets: []
manifests:
- manifest:
identifier: HarnessAppDemoManifests
type: K8sManifest
spec:
store:
type: Github
spec:
connectorRef: Platformdemo2
gitFetchType: Branch
paths:
- k8s/manifests/namespace.yml
- k8s/manifests/volumeclaim-creation.yml
- k8s/manifests/nodeport-deployment.yml
- k8s/manifests/ingress-deployment.yml
- k8s/manifests/app-deployment.yml
branch: main
skipResourceVersioning: false
- manifest:
identifier: values
type: Values
spec:
store:
type: Github
spec:
connectorRef: Platformdemo2
gitFetchType: Branch
paths:
- k8s/values/values.yml
branch: main
serviceRef: HarnessPlatformDemoApp
infrastructure:
environmentRef: k8sProduction
infrastructureDefinition:
type: KubernetesDirect
spec:
connectorRef: platformdemok8s
namespace: <+pipeline.variables.githublogin>
releaseName: <+pipeline.variables.githublogin>
allowSimultaneousDeployments: true
infrastructureKey: ""
execution:
steps:
- step:
type: HarnessApproval
name: Approve this version
identifier: Keep_this_Version
spec:
approvalMessage: Please review the following information and approve the pipeline progression
includePipelineExecutionHistory: false
approvers:
userGroups:
- account.Field_Engineering
- account.Harness_Partners
minimumCount: 2
disallowPipelineExecutor: false
approverInputs: []
timeout: 30m
failureStrategies:
- onFailure:
errors:
- Authorization
action:
type: StageRollback
when:
stageStatus: Success
- step:
name: Rollout Deployment
identifier: rolloutDeployment
type: K8sRollingDeploy
timeout: 10m
spec:
skipDryRun: false
- stepGroup:
name: Service Reliability
identifier: Service_Reliability
steps:
- step:
type: Http
name: API Verification
identifier: Smart_Verification
spec:
url: http://<+pipeline.variables.externalDnsName>/<+pipeline.variables.githublogin>/data/api.php?func=verif
method: GET
headers: []
outputVariables:
- name: message
value: <+json.object(httpResponseBody).message>
type: String
- name: level
type: String
value: <+json.object(httpResponseBody).level>
assertion: <+json.object(httpResponseBody).level> == "ok"
requestBody: test test test
inputVariables: []
timeout: 30s
failureStrategies:
- onFailure:
errors:
- AllErrors
action:
type: Ignore
- step:
type: Verify
name: Logs-Metrics Verification
identifier: verify_dev
spec:
type: Rolling
spec:
sensitivity: MEDIUM
duration: 5m
deploymentTag: <+serviceConfig.artifacts.primary.tag>
timeout: 2h
failureStrategies:
- onFailure:
errors:
- Verification
action:
type: StageRollback
spec:
timeout: 2h
onTimeout:
action:
type: StageRollback
- onFailure:
errors:
- Unknown
action:
type: ManualIntervention
spec:
timeout: 2h
onTimeout:
action:
type: Ignore
when:
stageStatus: Success
condition: <+pipeline.stages.Image_Deployment.spec.execution.steps.Service_Reliability.steps.Smart_Verification.output.outputVariables.level> == "error"
rollbackSteps:
- step:
name: Rollback Rollout Deployment
identifier: rollbackRolloutDeployment
type: K8sRollingRollback
timeout: 10m
spec:
skipDryRun: false
serviceDependencies: []
failureStrategies:
- onFailure:
errors:
- AllErrors
action:
type: StageRollback
variables: []
when:
pipelineStatus: Success
versionLabel: "6.0"
```
**Terraform Automation**
The Harness Terraform Provider enables automated lifecycle management of the Harness Platform using Terraform. You can onboard onto Harness on day 1 and also make day 2 changes using this Provider.
The Harness Terraform Provider allows you to define Harness resources (projects, services, environments, pipelines, connectors) as code. This is useful for onboarding multiple teams or replicating configurations across accounts.
The following Terraform script creates a project, Kubernetes connector, secret, service, environment, infrastructure definition, and pipeline. Customize the variable values in a `terraform.tfvars` file or pass them inline when running `terraform apply`. Key variables include `accountId`, `orgIdentifier`, `platform_api_key`, and connector details.
Go to [Onboard with Terraform Provider](/harness-ai/troubleshooting-and-resources/tutorials/onboard-terraform-provider.md) to learn more about the Terraform provider.
Terraform Script to create harness resources (Services, Environments, Pipelines)
```yaml
variable "platform_api_key" {}
variable "accountId" {}
variable "endpoint" {}
variable "projectIdentifier" {}
variable "orgIdentifier" {}
variable "connectorIdentifier" {}
variable "k8sMasterUrl" {}
variable "secretIdentifier" {}
variable "secretValue" {}
variable "serviceIdentifier" {}
variable "envIdentifier" {}
variable "infraIdentifier" {}
variable "pipelineIdentifier" {}
terraform {
required_providers {
harness = {
source = "harness/harness"
version = "0.16.1"
}
}
}
provider "harness" {
endpoint = "${var.endpoint}"
account_id = "${var.accountId}"
platform_api_key = "${var.platform_api_key}"
}
resource "harness_platform_project" "test" {
identifier = "${var.projectIdentifier}"
name = "${var.projectIdentifier}"
org_id = "${var.orgIdentifier}"
color = "#0063F7"
}
resource "time_sleep" "wait_30_seconds" {
depends_on = [harness_platform_project.test]
create_duration = "30s"
}
resource "harness_platform_secret_text" "inline" {
depends_on = [harness_platform_project.test, time_sleep.wait_30_seconds]
identifier = "${var.secretIdentifier}"
name = "${var.secretIdentifier}"
description = "example"
tags = ["foo:bar"]
org_id = "${var.orgIdentifier}"
project_id = "${var.projectIdentifier}"
secret_manager_identifier = "harnessSecretManager"
value_type = "Inline"
value = "${var.secretValue}"
}
resource "harness_platform_connector_kubernetes" "serviceAccount" {
depends_on = [harness_platform_project.test, harness_platform_secret_text.inline]
identifier = "${var.connectorIdentifier}"
org_id = "${var.orgIdentifier}"
project_id = "${var.projectIdentifier}"
name = "${var.connectorIdentifier}"
description = "description"
tags = ["foo:bar"]
service_account {
master_url = "${var.k8sMasterUrl}"
service_account_token_ref = "${var.secretIdentifier}"
}
}
resource "harness_platform_service" "example" {
depends_on = [harness_platform_project.test]
identifier = "${var.serviceIdentifier}"
org_id = "${var.orgIdentifier}"
project_id = "${var.projectIdentifier}"
name = "${var.serviceIdentifier}"
description = "description"
tags = ["foo:bar"]
yaml = <<-EOT
service:
name: "${var.serviceIdentifier}"
identifier: "${var.serviceIdentifier}"
tags: {}
serviceDefinition:
spec:
manifests:
- manifest:
identifier: manifest
type: K8sManifest
spec:
store:
type: Git
spec:
connectorRef: org.GitConnectorForAutomationTest
gitFetchType: Branch
paths:
- ng-automation/k8s/templates/
branch: master
valuesPaths:
- ng-automation/k8s/values.yaml
skipResourceVersioning: false
artifacts:
primary:
primaryArtifactRef: <+input>
sources:
- spec:
connectorRef: org.DockerConnectorForAutomationTest
imagePath: library/nginx
tag: latest
identifier: artifact
type: DockerRegistry
type: Kubernetes
EOT
}
resource "harness_platform_environment" "example" {
depends_on = [harness_platform_project.test]
identifier = "${var.envIdentifier}"
name = "${var.envIdentifier}"
org_id = "${var.orgIdentifier}"
project_id = "${var.projectIdentifier}"
tags = ["foo:bar", "baz"]
type = "PreProduction"
yaml = <<-EOT
environment:
name: "${var.envIdentifier}"
identifier: "${var.envIdentifier}"
description: ""
tags: {}
type: PreProduction
orgIdentifier: "${var.orgIdentifier}"
projectIdentifier: "${var.projectIdentifier}"
variables: []
EOT
}
resource "harness_platform_infrastructure" "example" {
depends_on = [harness_platform_project.test, harness_platform_environment.example]
identifier = "${var.infraIdentifier}"
name = "${var.infraIdentifier}"
org_id = "${var.orgIdentifier}"
project_id = "${var.projectIdentifier}"
env_id = "${var.envIdentifier}"
type = "KubernetesDirect"
deployment_type = "Kubernetes"
yaml = <<-EOT
infrastructureDefinition:
name: "${var.infraIdentifier}"
identifier: "${var.infraIdentifier}"
description: ""
tags: {}
orgIdentifier: "${var.orgIdentifier}"
projectIdentifier: "${var.projectIdentifier}"
environmentRef: "${var.envIdentifier}"
deploymentType: Kubernetes
type: KubernetesDirect
spec:
connectorRef: org.KubernetesConnectorForAutomationTest
namespace: default
releaseName: release-<+INFRA_KEY>
allowSimultaneousDeployments: true
EOT
}
resource "harness_platform_pipeline" "example" {
depends_on = [harness_platform_project.test]
identifier = "${var.pipelineIdentifier}"
org_id = "${var.orgIdentifier}"
project_id = "${var.projectIdentifier}"
name = "${var.pipelineIdentifier}"
yaml = <<-EOT
pipeline:
name: "${var.pipelineIdentifier}"
identifier: "${var.pipelineIdentifier}"
projectIdentifier: "${var.projectIdentifier}"
orgIdentifier: "${var.orgIdentifier}"
tags: {}
stages:
- stage:
name: stage
identifier: stage
description: ""
type: Deployment
spec:
deploymentType: Kubernetes
service:
serviceRef: "${var.serviceIdentifier}"
serviceInputs:
serviceDefinition:
type: Kubernetes
spec:
artifacts:
primary:
primaryArtifactRef: <+input>
sources: <+input>
environment:
environmentRef: "${var.envIdentifier}"
deployToAll: false
infrastructureDefinitions:
- identifier: "${var.infraIdentifier}"
execution:
steps:
- step:
name: Rollout Deployment
identifier: rolloutDeployment
type: K8sRollingDeploy
timeout: 10m
spec:
skipDryRun: false
pruningEnabled: false
rollbackSteps:
- step:
name: Rollback Rollout Deployment
identifier: rollbackRolloutDeployment
type: K8sRollingRollback
timeout: 10m
spec:
pruningEnabled: false
tags: {}
failureStrategies:
- onFailure:
errors:
- AllErrors
action:
type: StageRollback
variables:
- name: resourceNamePrefix
type: String
description: ""
value: qwe
EOT
}
```
YAML to use the above Terraform script in Harness pipeline as custom stage
```yaml
pipeline:
tags: {}
stages:
- stage:
name: Create Resource
identifier: Create_Resource
description: Create harness resources using Harness Terraform Provider
type: Custom
spec:
execution:
steps:
- step:
type: TerraformPlan
name: TerraformPlan
identifier: TerraformPlan
spec:
provisionerIdentifier: createResource
configuration:
command: Apply
configFiles:
store:
spec:
connectorRef: org.GitHubRepoConnectorForAutomationTest
gitFetchType: Branch
branch: master
folderPath: automation/terraform/K8sAutomation
type: Github
varFiles:
- varFile:
spec:
content: |-
platform_api_key = "Your Platform Api Token"
accountId = "accountID"
endpoint = "https://app.harness.io/gateway"
projectIdentifier = "Project Name to be created"
orgIdentifier = "Org where you want this project to be"
connectorIdentifier = "K8s Connector Identifier"
k8sMasterUrl = "K8s Master Url"
serviceIdentifier = "Service Identifier"
envIdentifier = "Environment Identifier"
infraIdentifier = "Infra Definition Identifier"
pipelineIdentifier = "Pipeline Identifier"
secretIdentifier = "Secret Identifier"
secretValue = "K8s ServiceAccount Token Secret Value"
identifier: terraformVariables
type: Inline
secretManagerRef: harnessSecretManager
timeout: 10m
- step:
type: TerraformApply
name: TerraformApply
identifier: TerraformApply
spec:
configuration:
type: InheritFromPlan
provisionerIdentifier: createResource
timeout: 10m
tags: {}
identifier: Harness_Terraform_Provider
name: Harness Terraform Provider
delegateSelectors: []
projectIdentifier: NGPipeAutoterraform_providerVcP4LI2gPm
orgIdentifier: Ng_Pipelines_K8s_Organisations
```
**Phase 5 outcome:** You have enabled SSO for seamless user authentication, created reusable templates to standardize pipelines across teams, and automated Harness resource provisioning using the Terraform provider. Your Harness deployment platform is now production-ready and scalable.
***
### Related concepts
Now that you understand the Harness CD onboarding journey, explore these related topics to deepen your knowledge:
* [CD pipeline modeling overview](/continuous-delivery/troubleshooting-and-resources/resources/new-user/cd-pipeline-modeling-overview.md): Learn how to structure multi-stage pipelines with dependencies and conditionals
* [Deployment concepts and strategies](/continuous-delivery/use-continuous-delivery/manage-deployments/deployment-concepts.md): Detailed comparison of rolling, blue-green, and canary strategies with use case guidance
* [RBAC in Harness](/harness-ai/use-harness-platform/platform-access-control.md): Configure roles, resource groups, and permissions for your team structure
* [Harness Terraform provider](/harness-ai/troubleshooting-and-resources/tutorials/onboard-terraform-provider.md): Automate Harness resource provisioning with infrastructure-as-code
* [Continuous Delivery tutorials](/continuous-delivery/troubleshooting-and-resources/tutorials/cd-gitops-tutorials.md): Hands-on quickstarts for Kubernetes, ECS, serverless, VMs, and more