DEV Community: Lavakush biyani ☄

Stop Letting Deployment Approvals Slow Down Your Releases

Lavakush biyani ☄ — Thu, 15 Oct 2026 11:03:12 +0000

TL;DR

Approvals shouldn’t cost you a shift. With Harness, the approval step lives inside your pipeline, so you get sign-off without the waiting and the glue code.

Key takeaways include:

Waiting on people is the real cost: Approval gates rarely fail because the check is wrong. They fail because someone isn’t free when the deploy needs them, and those hours add up fast.

Keep approvals in the pipeline: One approval step runs alongside your build and deploy. No separate tool, no webhook to wire up.

Measure ready-to-release time: Track the gap between staging validation and the next deployment, find where approvals stall, and fix that.

The Approval Gate That Costs You a Shift

Manual approval gates in front of the pre-prod stage don't fail because the check is wrong. They fail because they wait on a person, and a person isn't always available the moment a deployment needs one. A build that passes staging tests at 10 AM can sit blocked for hours waiting on a checklist that requires three separate sign-offs before anyone can click “Approve”. By the time all three land, it's 6 PM, the engineer who owns the next step has already left for the day, and the deployment slips to the next morning.

That's not a one-off. Across 12 releases last quarter, the same 4-hour-plus wait recurred, adding up to roughly two full working days of cycle time spent waiting on sign-offs, not shipping anything.

How a Single Execution ID helps

A Harness pipeline is a single execution graph, not two tools glued together by a webhook. Your staging and pre-prod stages sit inside the same pipeline object, sharing a single execution ID and timeline. There's no artifact handed off from a CI system to a separate CD system via a trigger or webhook payload. The same pipeline orchestration layer that started the run owns it end-to-end, from the first step to the last. That matters for what comes next, because it means a later stage can reference an earlier stage's output directly through an expression.

Bring the Approval Process Into the Pipeline
With Harness, teams can build approval gates directly into their deployment pipelines instead of stitching together a separate workflow for every release. This step slots into the same Staging-to-Pre-production pipeline covered in Deploy Your First App with Harness CD, right after the Deploy stage and before the pre-prod promotion. Once the staging checks are complete, the pipeline reaches the approval step. Harness notifies the configured reviewers, waits for the required approvals, and continues when the approval conditions are met.

This is the whole step, no separate approval-tracking tool, no webhook to wire up. Drop it into any CD stage and point userGroups at your release managers:

- step:
    type: HarnessApproval
    name: Release Manager Sign-Off
    identifier: ReleaseManagerSignOff
    spec:
      approvalMessage: |-
        Review this release before it proceeds to pre-production.
      includePipelineExecutionHistory: true
      approvers:
        minimumCount: 1
        disallowPipelineExecutor: false
        userGroups:
          - account.release_managers
      approverInputs: []
    timeout: 1d

The approval step sits within the same execution graph as the build and deploy stages, not bolted on alongside them.

Harness supports different approval approaches depending on how your organization works. A team can request direct sign-off through a Harness Approval step, use Jira Approval when the decision depends on a Jira issue, or use ServiceNow Approval when production changes are governed by a ServiceNow workflow. The Jira variant looks like this:


- step:
    type: JiraApproval
    name: Change Request Approval
    identifier: ChangeRequestApproval
    spec:
      connectorRef: jira_connector
      projectKey: REL
      issueKey: <+pipeline.variables.jira_ticket>
      approvalCriteria:
        type: KeyValues
        spec:
          conditions:
            - key: Status
              operator: equals
              value: Approved

The approval criteria are tied directly to the Jira issue’s status field; no separate polling or webhook needed.

The point is to fit the approval into the release process your organization already follows.

Spend Less Time Chasing Approvals
An approval request shouldn't leave reviewers wondering what they're being asked to approve.

When the relevant release context is readily available, reviewers can spend less time tracking down deployment details and more time making the decision. Teams can configure approvers, approval requirements, notifications, and timeouts to make the process more predictable.

Timeouts also help define what happens when an approval doesn't arrive. Rather than leaving a release blocked indefinitely, teams can configure the pipeline's failure behavior to align with their release policies, and for organizations that require formal change management, Jira and ServiceNow approval integrations can connect the deployment workflow to the relevant change request.

The result is a more consistent approval process, without requiring teams to build and maintain a custom approval mechanism for every pipeline.

Approval status sits right inside the pipeline execution

Keep Human Judgment Where It Matters

Not every release decision needs a person. Test results, artifact requirements, and other machine-verifiable conditions can often be checked automatically before an approval request is raised. Human approval can then focus on decisions that require accountability, business context, or explicit authorization.

Harness Policy as Code can be added when teams need custom, enforceable rules for release readiness. But when the requirement is simply to obtain a human sign-off, a native Harness Approval step is often all that's needed.

The distinction matters: automating the checks reduces manual verification, while streamlining the approval workflow makes it easier for the right people to act.

Measure the Time Between Ready and Released

The real measure of an approval workflow isn't how quickly a button can be clicked. It's how long a release waits after it's technically ready to move forward. Track the time between the completion of staging validation and the start of the next deployment. Look for recurring delays, identify where approvals get stuck, and use those findings to improve the workflow.

If your current process regularly adds hours of waiting, set a measurable improvement target and validate it against actual execution data. A release pipeline should make necessary controls easier to follow, not turn coordination into the longest stage of the delivery process.

Next up: Encoding release-readiness as Policy as Code. Once the sign-off step itself is fast, the next bottleneck is usually the checklist behind it: test status, artifact tag, ticket linkage, still being checked by eye. We’ll cover how to turn that checklist into an enforced OPA policy in the next piece.

Ready to streamline deployment approvals? Explore Harness Approval steps and see how they fit into your existing delivery workflow. If you’re starting from scratch, sign up for a free Harness account first, no credit card required.

Deploy Your First App with Harness CD in Under 15 Minutes

Lavakush biyani ☄ — Fri, 09 Oct 2026 05:14:57 +0000

Who this is for: Developers or platform engineers who have never run a Harness CD pipeline before. You'll need an SCM account, a Docker Hub (or similar) account, a Kubernetes cluster that a Harness Delegate can reach, and a Harness account. Once the delegate is connected, everything else in this walkthrough happens inside the Harness platform.

The problem with your first deployment

Most teams first few production deployments look the same: SSH into a container, git pull, rebuild, restart the service, and watch the logs for a minute to see if anything screams. It works, right up until it doesn't. A bad build ships, nobody's sure which commit is actually running, and rolling back means remembering the last image tag that worked and doing the whole manual process again, under pressure, at the worst possible time. That's usually 15-20 minutes of frantic SSH for something a rollback button should do in seconds.

That's not a tooling failure so much as a missing layer. Builds are automated. Deployments still aren't for many teams.

Two ways people usually solve this

Hand-roll it in your CI tool: If you're already on GitHub Actions, GitLab CI, or Jenkins, the path of least resistance is to bolt a deploy step onto the end of your build job: kubectl apply or a shell script over SSH. This is genuinely fine for a single service, a single environment, and a single person who understands the script. It stops being fine the moment you need a second environment, a rollback that doesn't involve re-running a script from memory, or an approval gate before production.

Adopt a dedicated CD tool: Splitting build (CI) from deploy (CD) means that the deployment itself, the environment it targets, the strategy it uses, and what happens if it fails become something you configure once and reuse, rather than being re-implemented in every pipeline's YAML. That's the trade you're making by picking this path: a bit more setup up front, in exchange for rollback, approvals, and audit history you don't have to build yourself.

We'll use Harness CD for the deep dive below, deploying a real Java application to a Kubernetes cluster. CD is one piece of Harness's broader Software Delivery Agent; the same governance and audit trail you'll see here also covers builds, infra, and artifacts, so this pipeline slots into a bigger picture rather than being a one-off tool.

Deploying the Sample Application with Harness CD

We're using the easybuggy-vulnerable-application as the sample application. It's a small Java/Tomcat app, and it already ships a working Dockerfile. The repo also has a .harness/ folder with a working pipeline definition already checked in. If you want the fast path, point Harness at that folder directly and skip to step 7. Otherwise, follow the steps below to build it yourself by hand, then compare what you built against that folder afterward.

1. Clone the repo and build the image

git clone https://github.com/harness-community/harness-sample-apps.git
cd harness-sample-apps/easybuggy-vulnerable-application

docker build -t <your-dockerhub-username>/easybuggy:v1 .
docker push <your-dockerhub-username>/easybuggy:v1

If the push succeeds, you'll see something like:

v1: digest: sha256:9f3a1c... size: 1786

That artifact digest is your proof that the image actually landed in the registry.

2. Point Harness at your cluster and your registry

In your Harness project, go to Project Settings → Connectors and create:

Docker Registry connector: A Docker Registry connector pointing at Docker Hub, using the same credentials you just pushed with.

Kubernetes Cluster connector: A Kubernetes Cluster connector pointing to the cluster you'll deploy to (your local kind cluster or a free-tier cluster works fine here). If you don't already have a Harness Delegate running in that cluster, the connector setup walks you through installing one: a lightweight agent that lets Harness reach the cluster and run deployments against it. Harness will hand you a helm install command.

helm repo add harness-delegate https://app.harness.io/storage/harness-download/delegate-helm-chart/ 
helm install my-delegate harness-delegate/harness-delegate-ng \
 --namespace harness-delegate-ng --create-namespace \
 --set delegateName=easybuggy-delegate \
 --set accountId=<your-account-id> \
 --set delegateToken=<your-delegate-token>

Once that pod is running in your cluster, the Delegates page in Harness (Project Settings → Delegates) will show it as Connected. That status, checked from within Harness, is your confirmation that Harness can reach the cluster; you don't need to inspect the cluster directly to know it worked.

3. Define the Service

A Harness Service is just "what am I deploying, and what does it look like when it's running." Create one service and give it two things: an artifact source (your Docker Registry connector, image easybuggy, tag v1) and a Kubernetes manifest. A bare bones manifest YAML for this app looks like:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: easybuggy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: easybuggy
  template:
    metadata:
      labels:
        app: easybuggy
    spec:
      containers:
        - name: easybuggy
          image: <+artifact.image>
          ports:
            - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: easybuggy-svc
spec:
  selector:
    app: easybuggy
  ports:
    - port: 8080
      targetPort: 8080
  type: LoadBalancer

The _<+artifact.image> _placeholder is Harness variable syntax. At deploy time, it's swapped for whatever image and tag you configured as the artifact source. See adding container images as artifacts for Kubernetes deployments for the full reference on wiring an artifact into a manifest this way. It's also how promoting a build from staging to production later becomes a config change instead of a YAML edit.

4. Define the Environment

A Harness Environment is the named target you're deploying to: dev, staging, or prod. It's kept separate from the Service on purpose, so the same "what am I deploying" definition from step 3 can be promoted through multiple environments later without being rewritten for each one. Create one infrastructure and call it dev.

5. Define the Infrastructure

Under that Environment, add an Infrastructure Definition. This is the specific place the deployment lands: pick Kubernetes, point it to the cluster connector from step 2, and set the namespace you want to deploy to (the default is fine for a first run).

If step 4 answers "which environment," this answers "which cluster and namespace, specifically."

6. Build the pipeline

Create a pipeline with a single Deploy stage:

Service: the one you just defined
Environment: dev
Execution strategy: Rolling. Harness generates the deploy steps for you; you don't need to hand-write this part.

7. Run it

Hit Run Pipeline. You'll watch a live console log scroll through roughly this shape:

Common first-run snags

A few things trip up almost every first Harness CD pipeline. Worth checking before you assume the pipeline itself is broken:

Delegate stays stuck on "Not Connected." Give it 60 to 90 seconds after the pod starts; the delegate needs to finish registering with Harness before a connector test connection will pass.

Image pull errors in the pod events: These show up in the execution log for the deploy step. Double-check the Docker Registry connector's credentials match what you used for docker push, and confirm the tag in the Service's artifact source is exactly v1, not latest, unless you pushed latest.

Pods are stuck in Pending: This is almost always the cluster not having enough allocatable CPU or memory for two replicas at once. Drop replicas to 1 in the manifest and redeploy to confirm that's the cause.

What "it worked" actually looks like

Two things prove this deployment did what it claims to have done, and neither one is a feeling:

Pipeline execution view: Every step green, a deploy log tied to a specific commit and image digest, and a timestamp. That's your audit trail, and it exists whether or not anyone was watching when it ran.

Safety net test: Roll something bad on purpose to see the safety net work. Push a tag that intentionally fails (an image name with a typo is enough), point the pipeline at it, and run it again. Harness will fail the rollout and mark the deployment for rollback: no SSH session. That one-click rollback is the actual point of this whole exercise. It's the difference between a deploy tool and a deploy script.

Once you've watched both a clean rollout and a rollback happen once, the numbers that used to be tribal knowledge (who deployed this, what image is actually live, how do we get back to the last good version) become answers you can pull from the pipeline execution log.

Try it yourself

Fork or clone easybuggy-vulnerable-application, point it at your own Kubernetes cluster, and run through the steps above end-to-end. Sign up for a free Harness account if you don't already have one; no credit card required.

If you built the pipeline by hand rather than using the fast path, diff it against the repo's .harness/ folder to see what you'd automate next: Git-based pipeline sync instead of clicking through the UI.

This walkthrough gets you a working rolling deployment to one environment. Next up: Add a Canary Deployment and Approval Gate to This Pipeline. We'll take the same Service definition, promote it to a second environment with manual approval, and swap the Rolling strategy for Canary so that a bad build only ever hits a fraction of the traffic before it's caught.