Skip to main content

Integrating CD with other Harness modules

Last updated on

This topic describes a few of the cross-module use cases in the Harness platform.

Harness Continuous Integration

You can couple Harness Continuous Integration (CI) and Continuous Delivery (CD) in a single pipeline.

You can use Harness CI as the first stage in the pipeline to build, test, and push your app to a repo, and then have a subsequent CD stage pull that app version from the repo and deploy it to a dev, QA, or prod environment.

Here's the YAML for a simple example that builds and pushes an app in the CI stage and then pulls and deploys the app in the CD stage.

YAML
pipeline:
name: tweety
identifier: tweety
projectIdentifier: CD_Docs
orgIdentifier: default
tags: {}
properties:
ci:
codebase:
connectorRef: tweetapp
build: <+input>
stages:
- stage:
name: Tweetapp
identifier: Tweetapp
type: CI
spec:
cloneCodebase: true
infrastructure:
type: KubernetesDirect
spec:
connectorRef: docimmut
namespace: default
automountServiceAccountToken: true
nodeSelector: {}
os: Linux
execution:
steps:
- step:
type: BuildAndPushDockerRegistry
name: Build Tweet App
identifier: Build_Tweet_App
spec:
connectorRef: Docker_Hub_with_Pwd
repo: cretzman/tweetapp
tags:
- <+pipeline.sequenceId>
service:
serviceRef: ""
variables: []
- stage:
name: deploy tweety
identifier: deploy_tweety
description: ""
type: Deployment
spec:
deploymentType: Kubernetes
service:
serviceRef: Tweety
environment:
environmentRef: Tweety
deployToAll: false
infrastructureDefinitions:
- identifier: Tweety
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
when:
pipelineStatus: Success
allowStageExecutions: true

Here's what the pipeline looks like in pipeline studio:

Here's the push step from the CI stage:

Note the <+pipeline.sequenceId> expression. This is used to tag the artifact pushed to Docker Hub. You can tag your artifact versions in a number of ways. The expression <+pipeline.sequenceId> is incremented each time the pipeline is run.

The expression <+pipeline.sequenceId> will be used in the subsequent CD stage to fetch the app version.

Learn more

This was just a simple introduction to the integration.

For a longer tutorial of Harness CI and CD integration, go to End-To-End CI/CD Pipeline.

Harness Chaos Engineering

The Harness Chaos Engineering (HCE) integration with Harness CD allows chaos experiments to be executed as part of a Harness CD pipeline.

Harness Feature Management & Experimentation

You can integrate Harness Feature Management & Experimentation into your Harness CD pipelines to manage feature flags as part of your deployment workflow.

By adding FME steps to CD stages, you can create, update, target, and disable feature flags during a pipeline execution. This allows feature flag operations to be versioned, reviewed, and executed alongside application deployments, reducing manual steps and improving release coordination.

You can integrate Harness FME with CD pipelines in the following ways:

  • Creating or updating feature flags as part of a release
  • Managing individual targeting lists during staged rollouts
  • Adjusting default traffic allocations when deploying a new version
  • Killing a feature flag immediately in response to deployment issues

For more information, see the Pipelines documentation.