Skip to main content

Developer day to day guide

This guide is intended to get users in the Developer role started with Harness CD.

For this guide, we assume you have set up the necessary Harness integrations (Harness Delegate, Kubernetes Cluster connector, AWS connector, JIRA connector, SSO configuration, etc.) and your Harness account configurations.

For onboarding your team, go to the Onboarding path.

For CD tutorials, go to CD and GitOps tutorials.

If you have any additional questions, reach out to us and our team will be happy to help!

What is Harness Continuous Delivery (CD)?

Harness CD is a cloud-native software delivery platform that automates the deployment process, helping teams to release applications quickly, securely, and reliably.

Harness simplifies complex CD tasks by providing features like automated rollback, deployment verification, and performance analysis. Harness integrates with all tools and platforms and offers insights into deployment metrics to optimize the release process.

Harness' goal is to increase deployment frequency, reduce failures, and provide a seamless experience for software delivery.

Performing a deployment

There are three Harness entities you will define when performing a deployment with Harness:

  • Service: What you are deploying.
  • Environment: Where are you deploying.
  • Pipeline: How are you deploying.

These entities are summarized below.

Services

You can define a Harness service in your Harness project. The service defines the application, microservice, serverless function, or other workloads you are deploying. For more information, go to Create services, Deploy services on different platforms, and Services and environments basics.

Environments

As you onboard more services, you will also need to onboard more Harness environments for the different business environments where you are deploying these services.

A common pattern is three environments:

  • Dev
  • QA
  • Prod

For more information, go to Environments overview and Services and environments basics.

Pipelines

To deploy your service, you need to model your release process using a pipeline. Harness offers a robust pipeline modeling experience that automatically adds the steps needed for all popular deployment types and strategies. Harness also lets you build pipelines from scratch. For an example using Kubernetes, go to Kubernetes deployments.

Pipeline example

Here's an example of a common Kubernetes pipeline.

To copy it and paste it into the YAML builder in your Harness project, select Deployments, Create a Pipeline, name the pipeline, and then use the YAML builder to update any settings.

Sample pipeline YAML
projectIdentifier: default
orgIdentifier: default
tags: {}
stages:
- stage:
name: deployKubernetes
identifier: Deploy_Kubernetes
description: Golden Kubernetes Deployment Stage
type: Deployment
spec:
deploymentType: Kubernetes
execution:
steps:
- step:
type: K8sDryRun
name: Dry Run
identifier: Dry_Run
spec: {}
timeout: 10m
- step:
type: HarnessApproval
name: Approval
identifier: Approval
spec:
approvalMessage: Please review the following information and approve the pipeline progression
includePipelineExecutionHistory: true
isAutoRejectEnabled: false
approvers:
userGroups:
- account._account_all_users
minimumCount: 1
disallowPipelineExecutor: false
approverInputs: []
timeout: 1d
- step:
type: K8sRollingDeploy
name: Rolling Deployment
identifier: RRolling_Deployment
spec:
skipDryRun: <+input>
pruningEnabled: false
timeout: 10m
- step:
type: K8sDelete
name: Cleanup
identifier: Cleanup
spec:
deleteResources:
type: ReleaseName
spec:
deleteNamespace: false
timeout: 10m
rollbackSteps:
- step:
name: Rollback Rollout Deployment
identifier: rollbackRolloutDeployment
type: K8sRollingRollback
timeout: 10m
spec:
pruningEnabled: false
services:
values: <+input>
metadata:
parallel: false
environments:
metadata:
parallel: true
values: <+input>
tags: {}
failureStrategies:
- onFailure:
errors:
- AllErrors
action:
type: StageRollback
- onFailure:
errors:
- AllErrors
action:
type: StageRollback
when:
pipelineStatus: Success
allowStageExecutions: true

Manually performing a deployment in Harness Manager

Depending on the project you have access to and the pipeline you have permissions to, a Harness user can log in and deploy a service using the Harness Manager UI.

To learn more, go to the Harness CD tutorials for various deployment types, or you can review Kubernetes deployments.

Video overview:

Automating deployments with triggers

With Harness triggers, you can start automating your deployments from any location, such as a source repository, an artifact repository, or a third party system.

Any Developer with pipeline create and edit permissions can configure a trigger in Harness. Developers who engage with the trigger's listening source (webhook, artifact repository, etc.) can fire off a trigger.

Let's look at an example of a GitHub webhook trigger automated deployment.

Here is the pipeline trigger in Harness.

Here's the webhook in GitHub.

Once the webhook is auto-created in your GitHub repository, Harness will receive Git events from the webhook to initiate pipeline execution.

In Harness, the trigger will indicate when it was activated.

Navigate to the Pipeline Executions page and you will see pipeline initiated by the trigger:

For more information, go to Trigger pipelines using Git events.

Automating deployments using the Harness API

If you are the pipeline executor, you can also initiate pipeline executions via API. The API lets you integrate with any third party system to initiate and pass parameters to a Harness pipeline.


curl -i -X POST \
'https://app.harness.io/pipeline/api/pipeline/execute/IDENTIFIER/inputSetList?accountIdentifier=string&orgIdentifier=string&projectIdentifier=string&moduleType=string&branch=string&repoIdentifier=string&getDefaultFromOtherRepo=true&useFQNIfError=false&notesForPipelineExecution=' \
-H 'Content-Type: application/json' \
-H 'x-api-key: YOUR_API_KEY_HERE' \
-d '{
"inputSetReferences": [
"string"
],
"withMergedPipelineYaml": true,
"stageIdentifiers": [
"string"
],
"lastYamlToMerge": "string"
}'

For more information, go to Execute a Pipeline with Input Set References.

Responding to Harness approvals

Many pipelines have approvals as quality gates. Approvals require developers to review the pipeline's progress to ensure nothing is going wrong.

Depending on your user group and access to the project, you can can see the approval action on the Home Screen.

And in the pipeline, you can view and add comments to your approval. This information will be stored and logged with the pipeline for auditing.

Select Approve and the pipeline will progress. If you reject the approval, the pipeline will end and initiate rollback or the pipeline failure strategy.

For more information, go to Using manual Harness approval stages, and the Approvals tutorial, and Notifications settings.

Assigning roles to new team members

If your Harness Administrator hasn’t set up the user groups, roles, and permissions for all your development teams, and if you are a Project Administrator, you can add your teammates to the project yourself.

For more information, go to Manage users.

Add pipeline notifications

If you are Pipeline Creator or Editor, you can add pipeline notifications to notify yourself and your teammates of deployment progress and status.

Harness integrates with Slack, Webhook, MS Teams, PagerDuty, and Emails. For more information, go to Notifications settings.

Reviewing deployments

After a deployment occurs, you want to know what was deployed and where, so you can track the version of a service or an artifact across different environments.

For more information, go to Monitor deployments and services in CD dashboards.

Go to Environments to see an environment. The summary dashboard will show what version of a service is deployed in your environment.

You can also view the same information from a service perspective.

Conclusion

Thanks for reading this Developer role ramp-up guide! If you have any feedback or suggestions on how to improve it, please reach out to us.