Continuous Delivery & GitOps Blogs

Why does achieving continuous delivery excellence feel like pushing water uphill when you already have CI/CD pipelines in place?

The problem is not the pipeline technology. It is the cognitive overhead surrounding it. Your developers spend more time navigating Slack threads about deployment permissions, hunting down environment configuration, and reverse-engineering service dependencies than actually shipping code. Meanwhile, your platform team fields the same integration questions every sprint, and your release velocity stalls because nobody trusts the golden path enough to use it consistently.

This is the reality of continuous delivery at scale. The tooling exists. The automation exists. What breaks down is the interface between platform capabilities and developer adoption. When deployment workflows remain tribal knowledge rather than encoded standards, continuous delivery becomes continuous friction.

The Gap Between Pipeline Capability and Delivery Velocity

Most organizations treat continuous delivery as a pipeline problem. They invest in sophisticated CI/CD orchestration, implement comprehensive testing frameworks, and automate infrastructure provisioning. Then they wonder why deployment frequency remains flat and lead time continues to drift upward.

The issue is abstraction mismatch. Your pipelines may be perfectly capable of handling complex deployment topologies, but if developers cannot discover how to trigger them, understand their prerequisites, or determine which pipeline applies to their service, that capability becomes effectively unavailable. You have built automation that requires manual intervention to use.

This manifests in predictable failure modes. Teams create shadow pipelines because the official ones are too opaque to configure. Service ownership becomes unclear because there is no single source of truth mapping teams to deployments. Environment promotion stalls because approval workflows exist in multiple systems without a unified state model. Each workaround adds technical debt that compounds deployment complexity.

Platform engineering teams recognize this pattern. They know that developer experience automation is not about building more features into the pipeline. It is about reducing the cognitive load required to use the pipeline correctly. The challenge is doing this without fragmenting standards or creating one-off solutions that do not scale.

Service Catalog Deployment as the Missing Integration Layer

An internal developer portal continuous delivery model treats the service catalog as the authoritative source of deployment context. Instead of requiring developers to maintain separate service definitions in multiple systems, the catalog becomes the integration point that connects service metadata to pipeline execution.

This changes the deployment contract. Rather than expecting developers to know which Jenkins job, GitHub Action, or deployment script applies to their service, the portal maps catalog entries directly to standardized deployment workflows. A service registered in the catalog automatically inherits the correct pipeline configuration, environment promotion logic, and governance guardrails based on its metadata.

The operational benefit is consistency. When every service follows the same registration and deployment pattern, platform teams can enforce policies at scale without manual review. Developers gain self-service deployment platform access without needing deep knowledge of the underlying pipeline infrastructure. The catalog becomes both the interface and the control plane for continuous delivery.

This approach also solves the ownership problem. Service catalog entries define not just what gets deployed, but who owns it, which team maintains it, and what dependencies exist. When a deployment fails, the on-call engineer does not need to hunt through Git history or Slack channels to determine responsibility. The catalog metadata makes ownership explicit and actionable.

IDP Workflow Orchestration Across the Delivery Lifecycle

Platform engineering CD pipelines become more than isolated automation scripts when orchestrated through a unified developer portal. The portal acts as the coordination layer that connects service definition, build execution, deployment triggering, and observability feedback into a coherent workflow.

Consider environment promotion. In traditional setups, developers manually trigger deployments to staging, wait for validation, then trigger production separately. Each step requires context switching between systems, manual verification of prerequisites, and tribal knowledge about approval requirements. The portal consolidates this into a single orchestrated flow where service metadata drives progression logic.

This does not mean embedding all pipeline logic into the portal. The portal remains the control plane while delegating execution to specialized tools. A developer initiates deployment through a standardized interface. The portal validates prerequisites based on service catalog metadata, triggers the appropriate pipeline in the underlying CI/CD system, tracks promotion state across environments, and surfaces deployment status alongside service health metrics.

The workflow orchestration extends beyond deployment execution. Pre-deployment checks verify that infrastructure dependencies exist, required secrets are configured, and governance policies are satisfied. Post-deployment validation confirms that health checks pass and observability signals match expected baselines. Rollback procedures become self-service actions tied directly to the deployment record rather than undocumented runbooks.

This orchestration model scales because it separates concerns correctly. Pipeline engineers focus on optimizing build and deployment mechanics. Platform engineers define golden paths and governance boundaries. Application developers interact with a consistent interface regardless of underlying complexity. Each layer operates independently while the portal maintains coordination state.

Continuous Delivery Best Practices Through Enforced Standards

Developer portal DevOps integration is not about exposing every configuration option. It is about encoding continuous delivery best practices into the default path. When developers create a new service through the portal, they automatically receive a deployment pipeline that implements your organization's standards for testing, security scanning, artifact management, and progressive delivery.

This opinionated approach reduces variability. Instead of every team making independent decisions about deployment strategy, the portal templates encode proven patterns. If your organization has determined that canary deployments with automated rollback are the safest approach for production releases, that becomes the default behavior for all services. Deviation requires explicit justification rather than accidental drift.

The enforcement mechanism is subtle but effective. Developers are not blocked from customization, but the path of least resistance is the standardized workflow. The portal makes it easier to follow best practices than to work around them. This shifts the burden of governance from reactive review to proactive design.

Documentation becomes embedded in the workflow itself. Rather than maintaining separate runbooks that describe how to deploy services, the portal surfaces contextual guidance at each decision point. Developers see inline explanations of why certain prerequisites exist, what each approval gate validates, and how to troubleshoot common deployment failures. The knowledge is distributed at the point of use rather than centralized in wikis that become stale.

Harness IDP: Connecting Service Catalogs to Continuous Delivery

Harness Internal Developer Portal addresses these integration challenges by treating the service catalog as the foundation for deployment orchestration. Instead of requiring developers to maintain service definitions separately from pipeline configuration, IDP provides a unified model where catalog entries drive deployment behavior.

When a service is registered in Harness IDP, it inherits standardized CI/CD scaffolding aligned with your platform policies. The catalog defines service ownership, dependencies, and deployment requirements as structured metadata. This metadata then controls which pipelines are available, what approval workflows apply, and how environment promotion progresses. Developers trigger deployments through self-service templates that validate prerequisites and enforce governance guardrails before execution.

The portal integrates directly with Harness Continuous Delivery pipelines, creating a closed-loop workflow from service definition to production deployment. A developer initiates deployment through the IDP interface. The portal validates that required infrastructure exists, secrets are configured, and policies are satisfied. It then triggers the appropriate Harness CD pipeline, tracks execution state across environments, and surfaces deployment status alongside service health metrics in a single view.

This integration extends to rollback and incident response. When a deployment fails or causes operational issues, the portal provides immediate access to rollback procedures tied to the specific deployment record. On-call engineers do not need to reconstruct deployment history or hunt through multiple systems to determine what changed. The service catalog maintains a complete audit trail of what was deployed, when, by whom, and what observability signals followed.

Platform teams configure golden paths once at the catalog level rather than reimplementing them for each service. A new microservice automatically receives the same deployment standards, security scanning, and progressive delivery patterns as existing services. Policy changes propagate consistently because they are defined in catalog templates rather than scattered across individual pipeline configurations.

For organizations running multi-module workflows, Harness IDP connects service catalog definitions to infrastructure provisioning and feature flag management. A service registered in the portal can declare its infrastructure dependencies, and those dependencies are validated before deployment proceeds. Feature flag state becomes queryable alongside deployment history, making it easier to reason about what is actually running in each environment.

Learn more about how Harness IDP standardizes deployment workflows. Find implementation guidance and integration patterns.

Building Continuous Delivery Excellence Through Platform Standardization

Continuous delivery excellence is not achieved by optimizing individual pipeline steps. It emerges from reducing the cognitive load required to deploy reliably at scale. When deployment workflows are encoded as platform standards rather than tribal knowledge, developers spend less time navigating process and more time shipping features.

The service catalog becomes the integration point that connects all continuous delivery concerns: service ownership, deployment pipelines, environment state, observability feedback, and incident response. By treating the catalog as the authoritative source of deployment context, platform teams can enforce governance without creating friction. The golden path becomes the obvious path because it is embedded in the workflow itself.

Organizations that achieve continuous delivery excellence recognize that tooling alone is insufficient. The socio-technical system surrounding deployment determines whether automation accelerates or impedes velocity. A developer portal that unifies service definition, pipeline orchestration, and operational visibility reduces fragmentation and makes best practices the default behavior.

If your deployment velocity is constrained by process overhead rather than pipeline capability, the interface layer between platform standards and developer workflows is where you should focus. Explore how Harness IDP reduces deployment friction and accelerates continuous delivery by providing self-service access to standardized pipelines.

• A DevOps automation platform connects build, test, deploy, security, and rollback in one workflow instead of a stack of disconnected scripts.
• An automation tool automates one step; a platform is workflow-aware and connects every step with shared context, permissions, and audit trail.
• DORA 2025: 90% of technology professionals now use AI at work, and that speed lifts delivery throughput but raises instability unless your automation can absorb the extra change safely.
• An AI-native platform recommends which tests to run, diagnoses failures, and remediates issues rather than just executing the steps you scripted.

What is a DevOps automation platform?

A DevOps automation platform is an integrated system that automates the repetitive, error-prone work across the software delivery lifecycle, covering builds, tests, deployments, security checks, and rollbacks in one place. Instead of wiring scripts and point tools together by hand, you get one workflow-aware platform that moves code from commit to production with less manual handoff.

• What it replaces: a patchwork of point tools, each automating one step and none aware of the others.
• What it automates: CI pipelines, deployment automation, infrastructure provisioning, security scanning, and incident response.
• What "AI-native" adds: test selection, failure diagnosis, anomaly detection, and auto-remediation.
• Who it's for: platform, DevOps, and engineering teams losing time to toolchain handoffs.

Walk into most engineering orgs and you will find too much automation, not too little, scattered across a CI runner here, deploy scripts there, and a monitoring tool nobody fully owns. What eats the week is wiring those scripts together and chasing what broke in the gaps between them. A DevOps automation platform folds that sprawl into one workflow, so engineers ship software instead of babysitting the glue.

What is the difference between an automation tool and a DevOps automation platform?

The difference decides whether automation actually pays off.

An automation tool does one job. Ansible configures servers, a CI runner executes builds, and a Terraform file provisions infrastructure. Each is good at its slice but blind to what runs before or after it. So you wire the slices together yourself, and every handoff drops context or triggers a manual step at 2 a.m.

A DevOps automation platform is workflow-aware. A build feeds a test stage, which feeds a deployment, which feeds a rollback policy, all sharing one context, one set of permissions, and one audit trail. With 60% of teams running more than five tools (GitLab 2025), the integration tax across those stacks is the real cost, not the tools themselves. Point automation speeds up a step. Platform automation speeds up the system.

What does a DevOps automation platform automate?

Automation takes repeatable work off your engineers across four areas. The table below maps what a platform replaces and why it matters.

On security: with 84% of codebases carrying at least one open-source vulnerability (Synopsys OSSRA 2024), in-pipeline scanning via Application Security Testing stopped being optional a while ago. The question is whether the scan happens inside your pipeline with an audit trail, or outside it where developers route around it.

What is an AI-native DevOps automation platform?

Rule-based automation runs the steps you scripted, the same way every time. An AI-native platform adds a layer that reads the situation and decides.

The difference shows up the moment something goes sideways. A scripted pipeline runs all 4,000 tests on a one-line change, then pages a human when it breaks. An AI-native one runs only the 40 tests that touch the change, and when something breaks it reads the logs, names the likely cause, and can roll back on its own. Test selection, failure diagnosis, anomaly detection, auto-remediation: all of it comes from one shift. The automation weighs what is in front of it instead of blindly running the steps.

Among teams leaning hardest on AI coding tools, 22% of deployments end in a rollback, hotfix, or incident (Harness, 2026 State of Engineering Excellence). When change volume climbs, scripted automation cannot tell a safe change from a risky one. That judgment is what an AI-native platform, grounded in the Software Delivery Knowledge Graph, adds.

How should you evaluate a DevOps automation platform?

Not every platform automates the same breadth, and the gaps are where bottlenecks hide. Run any candidate through this checklist:

• Automation coverage. Does it span the full software delivery lifecycle (CI, CD, security, infrastructure, cost, incident response), or just a slice?
• AI capabilities. Does the AI act on the pipeline (selecting tests, diagnosing failures, remediating), or only report on it from the sidelines?
• Pipeline authoring. Can teams build and reuse pipelines via a portal like the Internal Developer Portal without a dedicated scripting priesthood?
• Multi-cloud support. Does it run across the clouds and clusters you actually use?
• Governance and audit. Are RBAC, policy-as-code, and audit trails baked in, not bolted on?

One warning: a platform that automates only part of the workflow creates fresh bottlenecks at the handoffs it does not cover. Partial automation moves the wait; it does not remove it.

How Harness approaches automated DevOps at scale

The challenge

Most teams automate in fragments: a CI runner here, deploy scripts there, security tacked on at the end. The fragments do not share context, so every release still leans on manual judgment. That judgment is exactly what buckles when AI-assisted coding pushes change volume past what humans can review by hand.

The approach

Harness automates everything after code is written, on one platform. Continuous Integration speeds builds with test intelligence. Continuous Delivery and GitOps ships with progressive rollouts, automated rollback, and continuous verification. Infrastructure as Code Management provisions infrastructure through governed pipelines. Application Security Testing embeds scanning into the workflow. AI SRE reads logs and names the likely cause of failures. Cloud and AI Cost Management closes the loop on spend. The Software Delivery Knowledge Graph grounds every AI decision in your delivery data, while policy as code and RBAC keep the whole system governed. Developer-friendly guardrails.

The outcome

With the whole lifecycle automated, shipping stops being the risky part. Each change carries its own checks and a clean path back if it misbehaves, so the team spends fewer nights chasing incidents and more time on the decisions that genuinely need a person. Hundreds of engineering teams trust Harness to consolidate delivery and remove manual interventions.

What teams running automated DevOps report

Two teams, two stacks, one pattern: retiring glue code and manual steps returns engineering time to the work that actually needs it.

How did Citi move from build to production in under seven minutes?

Moving release onto Harness let Citi go from build to running in production in under seven minutes, with role-based controls over more than 20,000 people, most deploying several times a day, the bank reported.

“Harness CD let us release each change within minutes of a pull request being merged.”

Stefanos Piperoglou, Technical Program Manager, Citi

Source: Citi enhances software delivery with Harness CD

How did Meltwater scale to 1,200 pipeline executions a day?

After moving CI off Jenkins onto Harness, Meltwater now runs more than 1,200 pipeline executions a day, with CI adoption growing 3x to cover 50% of the engineering organisation, the company reported.

“Harness CI is extremely open and flexible. There's nothing holding you back from building and deploying the way you want. Jenkins was extremely rigid and wouldn't have allowed us to grow the way we have.”

Jim Sheldon, Principal Software Engineer, Meltwater

Source: Meltwater scales CI to 1,200 pipelines daily

The gain traces to one move: retiring glue code and manual steps, not stacking on more tools.

One system beats a pile of tools

A pile of point tools only takes you so far. A DevOps automation platform takes repeatable work off your engineers, connects every stage of software delivery, from build to production, and turns that pile into one system you can actually improve against DORA's delivery metrics. Start with breadth of coverage, demand AI that acts on the pipeline, and treat governance as a guardrail, not a gate. Get it right and the handoffs that used to eat your week quietly disappear.

See how Harness brings the full software delivery lifecycle onto one AI-native platform.

Dek: A self-propagating npm worm poisoned hundreds of packages and spread through legitimate publishing workflows. The incident exposes a critical distinction for software supply chain security: build provenance can be valid even when the source entering the build is malicious.

Based on public reporting available as of August 5, 2026, at 10:19 a.m. Central Time. Package and version counts may change as researchers continue investigating.

What happened

On August 4, a self-propagating npm worm spread from packages in the widely used keyv and cacheable ecosystem into packages controlled by multiple unrelated organizations.

SafeDep confirmed 2,234 poisoned versions across 444 package names and reported that the worm reached 12 organizations in less than four hours. Four foundational affected packages—keyv, flat-cache, file-entry-cache, and cacheable-request—collectively receive approximately 1.88 billion downloads per month.

Each malicious release added an npm preinstall hook that executed before installation completed. The payload searched developer machines and CI/CD environments for GitHub, npm, cloud, HashiCorp Vault, Kubernetes, database, and other credentials. It could also inspect GitHub Actions runner memory and use stolen npm publishing access to modify and republish additional packages.

Researchers also identified persistence mechanisms involving VS Code and Claude Code project configuration. Opening an affected repository in those tools could trigger malicious code independently of a normal package installation.

One of the most important response details is counterintuitive: the malware installed a monitor that could execute an attacker-controlled command when a stolen GitHub token stopped working. Teams therefore need to locate and remove that persistence mechanism before revoking or rotating credentials.

Why this matters

ChainDrop did not rely only on unsigned artifacts or an obviously unauthorized release process.

Some malicious packages were published through legitimate GitHub Actions and npm OpenID Connect trusted-publishing workflows. Those releases retained valid SLSA provenance because the authorized build system had, in fact, produced them.

The provenance was not technically false. It accurately identified the workflow that built and published the artifact. The failure occurred earlier: malicious source or workflow inputs had already entered the trusted process. As Socket summarized, provenance attested to build integrity, not source integrity.

That distinction matters for engineering and security leaders. Signing and attestation are important controls, but they cannot independently answer several essential questions:

• Was the source change reviewed and approved?
• Did the release correspond to an expected commit, pull request, and tag?
• Were workflow files or project configuration modified unexpectedly?
• Should this dependency be allowed to execute an install script?
• Did the build behave consistently with the package’s intended purpose?
• What identities and secrets could the build runner access?

A delivery system can be cryptographically verifiable and still faithfully build malware.

The business consequences extend beyond one poisoned dependency. Credentials taken from a developer workstation or runner can create access to source repositories, registries, cloud environments, clusters, secret stores, and downstream release workflows. What starts as a dependency incident can quickly become an identity compromise, a release-integrity problem, and an organization-wide response effort.

How teams can reduce the risk of similar incidents

Teams should treat provenance as one layer in a broader evidence chain rather than as a standalone trust decision. Provenance confirms how an artifact was produced, not whether the underlying source code is trustworthy.

Govern source and workflow changes. Protect branches, require independent review for release-related code, and apply additional scrutiny to package manifests, lifecycle scripts, CI workflows, editor tasks, and AI-agent configuration. A valid signature should not override an unexpected or unreviewed change.

Correlate releases with source events. Before permitting publication or promotion, verify that an artifact maps to an approved commit, pull request, tag, workflow version, and expected build identity. Unexpected patch releases or artifacts without corresponding source activity should be investigated.

Restrict install-time execution. Disable npm lifecycle scripts in CI where they are unnecessary. Where scripts are required, isolate their execution, monitor network and process activity, and explicitly allow only known behavior.

Use ephemeral, least-privilege identities. Prefer short-lived credentials with narrowly scoped permissions. A build that only needs to read dependencies should not have standing access to publish packages, modify repositories, enumerate cloud secrets, or reach production infrastructure.

Isolate runners. Use disposable build environments, minimize credentials present in memory, restrict outbound connectivity, and rebuild runners after suspected exposure. Long-lived, broadly privileged runners increase both the value of stolen credentials and the worm’s opportunity to persist.

Gate artifact publication and promotion. Evaluate more than signature status. Policies should consider source review, dependency risk, suspicious new scripts, unusual package behavior, scanner findings, and the relationship between the source repository and published artifact.

For this incident specifically, organizations should first hunt for the reported token-monitoring persistence, editor hooks, package IOCs, and unexpected releases. Credential revocation and rotation should then occur from a known-clean environment, followed by rebuilding affected systems and downstream artifacts.

How Harness could help

Harness positions software supply chain security as a combination of dependency governance, security testing, policy enforcement, artifact controls, and delivery evidence not merely the presence of an attestation.

Harness Supply Chain Security supports assessing software supply chain posture, governing open source dependencies using software bills of materials, and managing artifact promotion with SLSA attestations. Harness messaging also emphasizes workflows for rapidly responding to vulnerable or compromised components.

The broader Harness platform can enforce organizational policies through Open Policy Agent, apply security gates within delivery pipelines, use fine-grained access controls, and maintain audit trails. Harness Artifact Registry is designed to centralize artifacts and dependencies while enforcing quality and security standards.

Applied to an incident like ChainDrop, those capabilities could help teams:

• govern which open source dependencies and package versions are permitted
• enforce a minimum package-age policy to delay adoption of newly published dependency versions
• require security and policy checks before publishing or promoting artifacts
• correlate attestations with approved delivery processes
• limit problematic packages through automated policy enforcement
• identify where affected components are used
• preserve audit evidence for investigation and remediation

These controls would not make provenance infallible or guarantee prevention. They could, however, strengthen the surrounding guardrails, reduce exposure, improve visibility, and accelerate remediation when trust signals conflict.

The bigger trend

ChainDrop reflects three converging trends.

First, software supply chain attacks increasingly target identities rather than only source code. npm tokens, GitHub credentials, cloud identities, and CI/CD permissions let attackers move through the same trusted paths maintainers use.

Second, developer environments now include more executable surfaces. Package lifecycle hooks, IDE tasks, automation files, and AI coding-agent configuration can all become persistence or propagation mechanisms.

Third, security decisions increasingly require combined evidence. Provenance, code review, dependency intelligence, workflow history, policy results, and runtime behavior each answer different questions. None is sufficient by itself.

Harness take

ChainDrop shows that “signed” and “safe” are not synonyms. Modern software delivery needs to establish continuity of trust from the proposed source change through the workflow, artifact, promotion decision, and runtime—not simply verify the identity of the pipeline that produced the final package.

Closing

ChainDrop does not make provenance unimportant. It clarifies its proper role.

Attestations remain valuable evidence about how software was produced, but trustworthy delivery requires controls before and after the build: reviewed source, governed workflows, constrained identities, policy-gated artifacts, isolated execution, and evidence from runtime behavior.

Harness helps organizations connect these controls across the software delivery lifecycle so that a valid signature becomes one input to a risk decision—not the entire decision.

Key takeaways

• SafeDep confirmed 444 affected npm package names and 2,234 poisoned versions as of its August 4 analysis.
• The worm executed during package installation and targeted developer, CI/CD, cloud, registry, Vault, and Kubernetes credentials.
• Legitimate OIDC publishing workflows produced artifacts with valid SLSA provenance after malicious inputs entered the pipeline.
• Teams should remove the reported token-revocation persistence before rotating credentials.
• Provenance should be combined with source governance, policy gates, dependency controls, least-privilege identities, and runtime evidence.

FAQ

What is the ChainDrop npm worm?

ChainDrop is the name used for a self-propagating npm supply chain campaign that inserts credential-stealing malware into packages and uses compromised publishing access to infect additional packages.

How can malware have valid SLSA provenance?

Provenance verifies information about the build process and identity that produced an artifact. When an authorized workflow builds already-compromised source, the resulting attestation can be valid even though the artifact is malicious.

What should teams do if they installed an affected package?

Treat the relevant developer machine or build runner as potentially compromised. Hunt for the published persistence mechanisms and indicators first, then revoke and rotate exposed credentials from a clean environment and rebuild affected systems and artifacts.

‍

Q2 | May – July 2026

Welcome back to the quarterly update series! If you've been following along, Q1 2026 brought AI-powered continuous verification, expanded deployment platform support, and GitOps workflow enhancements. Q2 builds on those foundations with progressive Kubernetes canary rollouts, native AI agent deployments, sharper verification controls, and a wave of GitOps improvements — from one-click application rollback to finer-grained RBAC — that make self-service operations a reality for platform teams.

‍

Deployments

Kubernetes

Progressive Canary for Kubernetes

Harness now supports progressive canary deployments as a dedicated subtype of the Kubernetes Canary strategy. Instead of a single canary phase, you can define percentage-based rollout stages — for example, 25%, 50%, and 100% — with verification or approval gates between each phase. Harness maintains two Deployments and shifts replicas between them, keeping the total pod count within a fixed budget throughout the rollout. This gives platform teams a repeatable, observable path for shipping changes with automated quality gates at each step rather than a binary canary-or-full-traffic decision. Learn more about Kubernetes progressive canary deployments →

Kubernetes Blue-Green: Scale-Up on Rollback

When a Kubernetes Blue-Green deployment fails and triggers a rollback, Harness now automatically scales up the previous (stable) deployment after the services are swapped back. Previously, the stable deployment could be sitting at zero replicas during the rollout, meaning traffic routed to it immediately after the service swap would hit unscaled pods. The automatic scale-up eliminates this gap, ensuring traffic reaches active pods as soon as the rollback completes. Learn more about Blue-Green Scale Up on rollback →

Kubernetes Dry Run: Additional kubectl Flags

The Kubernetes Dry Run step now accepts additional kubectl flags — including --server-side and --force-conflicts — so the dry run validation command matches the actual kubectl arguments used at deploy time. Teams using server-side apply can now ensure that their dry-run output accurately reflects what will happen at deployment, making approval gates and policy checks more reliable. Learn more about the Kubernetes Dry Run step →

Istio Traffic Routing: AND/OR Match Logic

Istio traffic routing steps now support configurable AND/OR match logic for route rules. The new Match all rules option lets you require that every configured rule (URI, headers, method, port) match before a request is routed, rather than routing on any single match. This gives teams with complex traffic shaping requirements finer control over which requests reach canary or stage deployments. Learn more about the Traffic Shifting step →

Kubernetes Connector: Client Credentials OIDC Grant

The Kubernetes cluster connector now supports the client credentials OIDC grant type for machine-to-machine cluster access. In addition to the existing password grant, you can now authenticate with a client ID and client secret alone — suitable for scenarios such as AKS clusters fronted by Microsoft Entra ID, where a human user credential is neither available nor appropriate. Existing connectors are unaffected.

‍

AWS

Bulk Post-Production Rollback

When a bad release reaches multiple infrastructure targets simultaneously, you no longer need to roll back each one individually. From the service dashboard, you can now select multiple infrastructures where a service is deployed and roll them back together — choosing the target execution for each infrastructure before confirming the rollbacks. This compresses what was previously a tedious per-environment operation into a single coordinated action. Learn more about rollback deployments →

ASG MixedInstancesPolicy Support

AWS Auto Scaling Group deployments now support MixedInstancesPolicy, enabling the use of spot instances and automatic fallback under capacity constraints. You can configure the policy in the ASG configuration JSON to allow AWS to select from multiple instance types, and Harness automatically detects and updates the launch template version within the MixedInstancesPolicy during deployments. This opens cost optimization options for teams running non-critical workloads on spot capacity without sacrificing deployment automation. Learn more about MixedInstancesPolicy →

AWS CDK on ECS Delegates

AWS CDK steps can now run on ECS-based delegates, removing the requirement for a Kubernetes delegate runtime to execute CDK synth and deploy steps. Teams running hybrid or ECS-only delegate fleets can now use CDK provisioning without having to stand up a dedicated Kubernetes delegate. Learn more about AWS CDK on ECS delegates →

Smart CDK Diff: Skip Deploy When No Changes

Harness now supports automatic skipping of AWS CDK Deploy steps when a preceding CDK Diff step detects no infrastructure changes. This prevents pipelines from executing a no-op CDK deploy when only the application code has changed, but the infrastructure definitions have not, reducing end-to-end pipeline runtime. Learn more →

ECS Rolling: Skip Application Auto Scaling

ECS Rolling deployments now support a Skip application auto scaling option that tells Harness to bypass all AWS Application Auto Scaling API calls for that deployment. This is designed for teams that manage auto-scaling externally (outside of Harness service definitions), and for scenarios where many ECS services are deployed in parallel, and the volume of scaling API calls risks hitting AWS rate limits. Learn more →

OIDC Environment Session Tags for AWS

AWS connectors with OIDC authentication now include environment identifiers as session tags in OIDC tokens. This lets you enforce environment-specific IAM policies — for example, restricting access to production secrets to pipelines running in production environments — while sharing a single delegate pool across environments. You no longer need separate connectors or delegates to achieve environment-level IAM isolation. Learn more about OIDC environment-based session tags →

‍

Google Cloud

MIG Blue-Green: Pre-Traffic Staging Deployment

Google Managed Instance Group (MIG) Blue-Green deployments now expose a staging deployment step before the traffic shift so that you can test and validate the new MIG version — including running pre-traffic checks and approval gates — before any live traffic is shifted to it. This closes a gap for teams that need to exercise the new MIG at scale before committing to the shift. Learn more about MIG Blue-Green deployments →

OCI Helm Charts from Google Artifact Registry

You can now use OCI-based Helm charts stored in Google Artifact Registry (GAR) as a manifest source for Helm deployments, expanding the set of OCI Helm registries Harness supports natively alongside ECR, Docker Hub, and others. Learn more about Helm chart cloud providers →

‍

AI Agent Deployments

Harness now natively supports deploying AI agent workloads as a dedicated deployment type in Harness CD — the first CI/CD platform to offer first-class pipeline automation for AI agent services.

This release adds out-of-the-box support for two agent runtimes: **AWS Agent Core** and **Google Agent Runtime**. You can model an AI agent service in Harness the same way you would any other service — define the artifact, configure the infrastructure, and attach a deployment pipeline. From there, all the same pipeline primitives apply: approval gates before a new agent version goes live, canary phases to validate agent behavior under partial traffic, automatic rollback when a verification step fails, and OPA policy checks before any agent deployment reaches production.

For platform teams managing a growing portfolio of AI agent workloads, this means agent deployments stop being one-off automation scripts and become first-class, auditable, policy-governed releases alongside the rest of your software. Explore AI Agent Deployments →

Traditional (SSH / WinRM)

Shell Script Step: Harness ID Tokens

The Shell Script step now supports Harness ID tokens via named identities. You declare one or more named identities on the step, and Harness generates an independent OIDC ID token for each, injecting it into the script as an environment variable at runtime. Scripts can then authenticate as the workload itself rather than through a connector, enabling fine-grained, per-script identity for sensitive automation tasks. Learn more about Harness ID tokens for the Shell Script step →

Preserve Directory Structure in Command Step Copy

The Copy command in the Command step now includes a Preserve Directory Structure option that maintains the original directory hierarchy when copying config files to target hosts. This prevents silent data loss from overwriting when multiple config files share the same name but reside in different subdirectories — a common pattern in multi-environment or multi-region SSH/WinRM deployments. Learn more about preserving directory structure →

‍

Connectors

Artifactory OIDC Authentication

The Artifactory connector now supports OIDC authentication, enabling credential-free federated authentication with JFrog Artifactory using short-lived JWT tokens. This eliminates the need to store static Artifactory credentials as Harness secrets and integrates Artifactory into the same keyless authentication model already available for AWS, GCP, and Azure connectors. Learn more about Artifactory OIDC authentication →

‍

Approvals

Approval Steps Inside Container Step Groups

Container Step Groups run all steps inside a single Kubernetes pod, which previously meant any pipeline that paused for human approval risked hitting the pod's 24-hour TTL before the approver responded. Harness now supports Harness Approval steps natively within Container Step Groups, and the pod's TTL automatically extends to match the stage timeout if it exceeds 24 hours. This removes the ceiling on containerized deployment workflows that span multiple time zones, require cross-team sign-off, or sit between canary and full-traffic phases. Note that only Harness Approval steps are supported inside Container Step Groups — Jira, ServiceNow, and Custom Approval types are not. Learn more →

Approval Visibility for Non-Approvers

Approval steps now support configurable visibility for non-approvers, letting users without approval permissions view step details during pipeline execution while keeping approval actions disabled. This is particularly useful for on-call engineers who need to monitor the approval status of an active deployment without approval authority. Configured at the project level under Default Settings. Learn more about approval visibility →

‍

Email Step

Email Step: Continue Send

The Email step now supports a non-blocking send mode, allowing pipeline execution to continue immediately after the email is dispatched, without waiting for delivery confirmation from the mail server. This removes an unnecessary blocking dependency for notification workflows where timely pipeline progress matters more than confirmed delivery. Learn more →

Verification

Git Experience for Monitored Services

Harness now supports Git Experience for monitored services, enabling version control and code review workflows for verification configurations. You can store monitored service configurations in your Git repository alongside the application code they verify, treat changes to health sources and SLOs as reviewable pull requests, and roll back verification configurations with standard Git operations. Learn more about Git Experience for monitored services →

AI Verify: New Configurable Properties

The AI Verify (v1) step now supports two additional **configurable properties** beyond the existing `deploymentStartTime`:

• dataCollectionDuration — Override the default data collection interval. Accepts a positive integer (number of minutes, maximum 60).
• customVerificationStartTime — Shift the verification window start to an earlier timestamp so that data from your health source already recorded between the deployment start and the Verify step execution is included in the analysis. Useful when:
  
  • Your observability tool (such as Dynatrace) begins recording immediately at service start
  • You have additional steps between your deployment step and the Verify step
  • Deployment and verification run in separate pipeline stages

Learn more about AI Verify configurable properties →

Per-Metric Sensitivity Override in AI Verify

The AI Verify step now supports per-metric sensitivity overrides, allowing you to set different sensitivity levels for individual metrics rather than applying a single threshold across the entire verification run. This means you can configure strict sensitivity for latency metrics and relaxed sensitivity for noisy metrics like memory usage — within the same Verify step — rather than tuning the global threshold to a compromise value. Learn more about per-metric sensitivity override →

CloudWatch: Full Metrics Insights Query Support

The CloudWatch health source now fully supports the complete CloudWatch Metrics Insights SQL syntax, including WHERE and ORDER BY clauses. You can now filter metrics by dimension values — for example, isolating metrics for a specific ALB target group, EC2 instance, or EKS namespace — directly in the query field. This is particularly useful for Continuous Verification comparisons: configure separate metric definitions with WHERE clauses targeting each group's dimensions to compare control and test traffic during blue/green or canary deployments. Learn more about CloudWatch health sources →

‍

‍

GitOps

Application Rollback

You can now roll back a GitOps application to a previous deployment directly from the Harness UI. A new History & Rollback tab on the application details page shows the full deployment history and lets you select a version to roll back to. Rollback is also available as a dedicated pipeline step, making it composable with approval gates and automated verification in your GitOps pipelines. Learn more about syncing and rolling back GitOps applications →

Applications in Any Namespace

GitOps now supports Applications in Any Namespace. When you configure a cluster-scoped agent, you can specify applicationNamespaces to allow ArgoCD Application resources to be created in namespaces outside the agent's install namespace. This removes a longstanding constraint for multi-tenant clusters where different teams need application isolation without per-team agents. Learn more about applications in any namespace →

Force-Delete Unreachable Applications

You can now force-delete a GitOps application from Harness when the underlying ArgoCD application is unreachable — for example, when the agent or ArgoCD project has been deleted. The Delete from Harness option removes the application record without requiring connectivity to the agent, unblocking cleanup workflows that previously got stuck when infrastructure was partially torn down. Learn more about managing GitOps applications →

Fine-Grained RBAC for Application Resource Actions

GitOps now enforces finer-grained RBAC, separating application-level operations (create, edit, delete) from Kubernetes resource actions (sync, restart, delete pod). This lets you grant operators the ability to restart pods or sync applications without granting them the ability to delete the application definition itself — a meaningful privilege boundary in shared platform environments. Learn more about managing GitOps access →

Squash and Merge in PR Pipelines

GitOps PR pipelines now support squash-and-merge when closing a GitOps pull request. Instead of a standard merge commit, Harness will squash all commits on the PR into a single commit before merging, keeping the release repository history clean and readable. This is especially useful for teams with many incremental commits per deployment that want a one-commit-per-release history in their release repo. Learn more about PR pipelines →

Selective Sync for GitOps Applications

The GitOps Sync step now supports selective sync — letting you choose a specific subset of resources to sync rather than syncing all resources in the application. Useful for large applications where you need to apply a targeted change without touching unrelated resources. Learn more about syncing GitOps applications →

Update Release Repo: Succeed When No Files Changed

The GitOps Update Release Repo (URR) step now supports an option to succeed even when no files are changed in the PR. Previously, the step always failed when there was nothing to commit, which blocked pipelines where the deployment state was already current. Teams using URR in pipelines that may or may not produce a change can now configure the step to treat a no-op commit as a success rather than a failure. Learn more about the Update Release Repo step →

Harness AI for GitOps

Harness AI now supports GitOps entities and pipeline stages. When creating or troubleshooting GitOps Applications or ApplicationSets, the AI can diagnose common setup errors and suggest remediations — including manifest syntax errors, incorrect service or environment types, missing GitOps clusters on linked environments, incomplete manifests, and connectivity issues with Git or infrastructure connectors. Learn more about Harness GitOps →

Zero Trust Service for Agent Communication

The GitOps agent now supports the Zero Trust Service (ZTS) for agent-to-SaaS communication, routing task parameters through the ZTS validation flow. This brings GitOps agent communication in line with the Zero Trust security posture available across other Harness services. Learn more about installing the GitOps agent →

ArgoCD 3.3.10 Bundled in GitOps Agent

The GitOps agent now bundles ArgoCD 3.3.10 (upgraded through the quarter from 3.3.9), incorporating the latest security fixes, stability improvements, and Helm and Kustomize updates from the ArgoCD project. Learn more about the GitOps agent →

‍

Repository Templates Across Scopes

You can now select repository templates from different scopes (account, organization, or project) when configuring GitOps repositories. Teams with shared repository templates defined at the account or org level no longer need to duplicate them at the project level to make them available during repository configuration. Learn more about GitOps repository credentials templates →

---

What's Next

Q3 will continue to expand Kubernetes-native deployment capabilities, streamline management of large-scale GitOps setups, and extend AI-assisted operations across more CD workflows. Explore the Harness Developer Hub for full documentation.

‍

Q2 | May – July 2026‍

Companion post: [Q2 26 CD & GitOps update →]

‍

Q2 2026 advances Harness Pipeline with DAG-based execution, smarter looping strategies, enhanced governance tooling, and a wave of improvements in reliability and developer experience. The quarter's headline feature — DAG pipelines — fundamentally changes how you model complex multi-stage workflows by letting stages declare explicit dependencies rather than relying on sequential order. Combined with improved cron scheduling, template label management, and a new pipeline dry-run API, Q2 gives teams greater control over how their pipelines are structured and validated. See the [Q1 2026 Pipeline update] for prior context.

‍

---

‍

Pipeline Execution

‍

DAG Pipelines (Beta)

‍

Harness now supports Directed Acyclic Graph (DAG) pipelines, enabling you to define explicit dependencies between stages instead of relying on sequential or parallel stage order. Each stage declares the stages it must complete before it starts via the dependsOn field, so independent execution paths progress as soon as their dependencies finish — without waiting for unrelated stages to complete. This unlocks execution patterns that are common in CI but historically difficult to model in CD: fan-out/fan-in topologies, diamond-shaped dependency graphs, and multi-path workflows where different service groups deploy in parallel but converge on a shared integration step.

Learn more about DAG pipelines →

‍

Pipeline Chaining with Looping Strategies

‍

Pipeline chaining now supports looping strategies when a parent pipeline calls a child pipeline, so you can run a child pipeline multiple times across a matrix or repeat configuration. Previously, chaining was limited to a single child pipeline invocation per stage. Teams that deploy to multiple environments or regions by parameterizing a shared child pipeline can now drive those invocations directly from the parent's looping strategy rather than duplicating stages.

‍Learn more about pipeline chaining →

‍

Matrix Exclusions Evaluated at Loop Start

‍

Matrix looping strategies now evaluate and exclude conditions at the beginning of the loop, removing excluded combinations before iterations start, rather than skipping them mid-execution. This change eliminates "skipped" iterations from cluttering your execution view and makes matrix execution counts predictable — the number of running iterations you see matches the number that will actually do work. 

Learn more about matrix looping strategies →

‍

Barrier Cycle Detection

‍

Harness now detects barrier reference cycles and enforces unique barrier references within a stage or step group, preventing circular barrier dependencies that could deadlock a pipeline. Pipelines with cycle configurations will fail validation at save time rather than silently deadlocking at runtime — a much faster feedback loop for teams using barriers to synchronize parallel deployments.

Learn more about barriers →

‍

Cron Triggers with AND Semantics

‍

Cron triggers now support AND semantics for complex scheduling where both a date range and a day-of-week condition must be satisfied simultaneously. For example, 0 3 16-22 * 1 executes at 3:00 AM UTC only on Mondays between the 16th and 22nd of the month. This enables precise scheduling for monthly maintenance windows, release cycles, and compliance-driven deployment schedules without scripting workarounds. 

Learn more about cron triggers →

‍

Governance & Policy

‍

Harness AI for OPA Policies

‍

OPA policy authoring now uses the unified Harness AI agent for enhanced, context-aware policy generation. Powered by specialized skills trained on OPA and REGO best practices, the AI assistant helps you write policies without deep REGO knowledge and generates plain-language descriptions of existing policies. Teams can iterate on governance rules faster, with less reliance on REGO specialists.

Learn more about building policies with Harness AI →

‍

Policy as Code: 6-Month Evaluation Data Retention

‍

Harness now retains Policy as Code evaluation data for 6 months by default. If your account has a pipeline data retention policy that exceeds 6 months, your OPA evaluations retention automatically aligns with the longer window. You can download evaluation data for compliance purposes or request a custom retention period. This closes a gap for compliance teams that needed evaluation history for audit trails beyond short-term retention windows. 

Learn more about policy evaluations retention →

‍

Policy as Code: Cloud Storage for Evaluation Inputs

‍

Large OPA evaluation inputs (pipeline YAML, Terraform plans, IaCM stacks) are now stored in cloud storage (GCS/S3) rather than the database, optimizing database performance for accounts with high evaluation volumes. Evaluation results and metadata remain in the database for fast access. A new signed URL API endpoint (GET /api/v1/evaluations/evaluation-input-signed-url/{id}) lets you retrieve input data from cloud storage when needed. 

Learn more about how evaluation data is stored →

‍

Executions Management Page

‍

A new Executions Management page gives you account-level visibility into all queued and running pipeline executions. You can see queue positions, monitor execution status across organizations and projects, and abort individual or bulk executions from Account Settings > Security and Governance > Executions Management. This is the operational view platform teams have needed for managing execution backlogs and diagnosing concurrency issues without diving into individual project views.

Learn more about Executions Management →

‍

Templates & Input Sets

‍

Template Overrides

‍

Templates now support configurable overrides, letting template owners designate specific advanced settings that callers can override without editing or duplicating the template. The template owner marks settings as overridable in the template's allowedOverrides list — including conditional execution, failure strategy, looping strategy, delegate selectors, and policy enforcement — and each caller that references the template can supply its own value for any allowed setting via templateOverrides in YAML. Any setting not listed in allowedOverrides remains locked to the template's value. A common use case: a stage template used across 50 pipelines sets a default conditional execution rule, and a single pipeline that needs different behavior overrides just that one setting instead of maintaining a duplicate template. Supported for step, stage, step group, and pipeline templates. 

Learn more about template overrides →

‍

Template Labels

‍

Harness now supports template labels for referencing template versions using semantic names instead of fixed version numbers. Labels let you create stable, human-readable pointers like stable, latest, or team-approved that you update as your template evolves, so pipelines that reference a label automatically pick up new template versions without requiring each pipeline to be updated. 

Learn more about template labels →

‍

Pipeline Dry Run Validation API

‍

A new dry run validation API endpoint lets you validate pipeline YAML changes while editing files in Git before committing them to your repository. The endpoint performs YAML schema validation, template expansion, and OPA policy evaluation without executing the pipeline — providing the same validation feedback you get from the Harness UI editor to Git-native workflows and CI checks. Available at POST /pipeline/api/v1/orgs/{org}/projects/{project}/dry-run. 

Learn more about pipeline YAML validation →

‍

Tag Filtering with AND/OR Logic

‍

Pipeline execution filtering by tags now supports AND/OR logic, enabling Matches Any (OR) or Matches All (AND) filtering. Teams using tags to label executions by environment, team, or release train can now run more expressive queries across their execution history without filtering results manually after fetching.

‍

Git Experience

‍

Git Tags for Pipeline and Input Set Sources

‍

Pipeline YAML and input sets stored in Git can now be referenced using Git tags in addition to branch names during trigger-based executions. Use the $tag:<tag-name> format in the Pipeline Reference Branch or Input Set Source fields (for example, $tag:v1.0.0), or resolve tag names dynamically from trigger expressions. This enables version-controlled pipeline configurations that align with your release workflow — triggering on a Git tag runs the pipeline and input set version that matches that tag, making rollbacks to prior configurations as simple as re-running against the original tag. Requires delegate version 26.04.89002 or later. Learn more about Git tag support →

‍

Git Experience Monitoring & Observability

‍

A new Webhooks monitoring section gives you full visibility into the health of your Git Experience. The Events tab shows the complete history of webhook events processed by Harness, with per-event payloads and troubleshooting details for synchronization failures. The new Observability tab goes further — it surfaces repository synchronization health across all Git-backed repositories (showing webhook coverage and sync status at a glance) and tracks Git provider API rate-limit consumption per connector, so you can identify which connectors are approaching rate limits before they cause sync failures. 

Learn more about monitoring Git Experience →

‍

Input Set Caching

‍

The Harness Git cache now extends to remote input sets, joining remote pipelines and templates. Input sets stored in Git are cached and served from the cache in the UI, reducing load times when opening or editing input sets for large repositories. A new refresh-and-get API endpoint lets you programmatically clear and refresh the cache for a specific branch, returning the refreshed entity in a single call — the API equivalent of the Reload from Git UI action. 

Learn more about Git caching →

‍

Git-Based Pipeline YAML in Dynamic Stages

‍

Harness now supports Git-based pipeline YAMLs in Dynamic Stages, allowing you to execute pipeline YAMLs stored in Git repositories in addition to inline and runtime-provided YAML. You can optionally specify a commit hash to pin execution to a specific version of the file — useful for audit trails and reproducible pipeline runs.

‍

Notifications & Observability

‍

Multi-Line String Variables

‍

String variables at pipeline and stage scope now support a multi-line input mode. With this feature enabled, any variable marked as multi-line expands to a resizable text area wherever users are prompted for that variable's value — in the run pipeline dialog, in input sets, and in the pipeline editor. This removes the friction of editing long structured values like YAML configuration blocks, lists of IP addresses, or shell script snippets through a single-line input. Learn more about variables →

‍

"Waiting for User Action" Pipeline Notification Event

‍

Harness now fires a "Waiting for User Action" notification event whenever a pipeline pauses for user input— such as Approval steps, Manual Interventions, or runtime input requests. You can configure these notifications at both the pipeline level and through centralized notification rules, enabling on-call routing, Slack alerts, or webhook integrations that fire precisely when a human action is blocking a deployment. 

Learn more about pipeline notifications →

‍

What's Next

‍

Q3 FY27 will continue expanding pipeline execution models, deepen template and Git Experience integrations, and bring further improvements to the governance and observability layer. Explore the Harness Developer Hub for full documentation.

‍

Modern software releases rarely consist of application code alone. A new feature might require additional database tables, modified columns, new indexes, updated constraints, or reference data changes. While many organizations have successfully automated application deployments, database schema migrations often remain disconnected from the rest of the software delivery process.

This separation creates deployment bottlenecks, increases operational overhead, and introduces unnecessary risk.

Application teams may deploy code through automated Continuous Delivery (CD) pipelines, while database changes are managed through separate processes, manual approvals, or standalone tooling. The result is a fragmented release workflow where application and database changes must be done manually. In this article, we'll explore how Harness Continuous Delivery (CD) and Harness Database DevOps (DBDevOps) enable teams to deploy database and application changes through a unified pipeline, improving release velocity, visibility, governance, and deployment safety.

Why Database Schema Migrations Should Be Part of Your CD Pipeline?

Applications and databases are now a days mostly tightly coupled and an application release may depend on:

• New tables
• Additional columns
• Updated indexes
• Modified constraints
• New database objects

When application deployments and database schema migrations happen independently, teams often encounter several challenges.

Manual Coordination

Application and database teams must coordinate release schedules and deployment windows.

Deployment Risk

Applications may be deployed before required database changes are available, resulting in runtime failures or broken functionality.

Limited Visibility

Teams often struggle to answer questions such as:

• Which database schema migrations have been deployed?
• Which environments are running the latest schema version?
• What changes were included in a release?

Complex Rollbacks

• Application rollbacks are generally straightforward.
• Database rollbacks can become significantly more complicated when deployments are managed through separate workflows.
• A unified deployment process helps eliminate these challenges by treating database schema migrations as a first-class part of software delivery.

What a Unified Deployment Pipeline Looks Like

Instead of managing application and database releases separately, teams can orchestrate both through a single deployment pipeline.

This approach ensures database and application changes remain synchronized throughout the deployment lifecycle.

Deploying Database Schema Migrations and Applications Together

Let's examine a practical example using Harness Database DevOps and Harness Continuous Delivery. The deployment stage consists of three primary phases:

1. Apply database schema migrations
2. Deploy the application
3. Verify deployment health and initiate rollback when necessary

Phase 1: Apply Database Schema Migrations

The deployment begins by applying database changes using the Harness Database DevOps schema deployment step.

- step:
    type: DBSchemaApply
    name: Apply Database Schema
    identifier: Apply_Database_Schema
    spec:
      connectorRef: account.harnessImage
      migrationType: Liquibase
      dbSchema: bookkeeper
      dbInstance: goodinstance
      tag: v1.0.0

The DBSchemaApply step executes the database schema migration associated with the specified release version. By versioning database changes and deploying them through a pipeline, teams gain:

• Consistent database schema migration across environments
• Controlled promotion between development, staging, and production
• Deployment traceability
• Improved governance and auditability

Most importantly, database changes are deployed automatically as part of the release process rather than through a separate operational workflow.

Phase 2: Deploy the Kubernetes Application

After the database schema migration completes successfully, the pipeline proceeds with the application deployment.

- step:
    name: Deploy Application
    identifier: rolloutDeployment
    type: K8sRollingDeploy
    timeout: 10m
    spec:
      skipDryRun: true
      pruningEnabled: false

The K8sRollingDeploy step performs a rolling deployment to Kubernetes, gradually replacing existing application instances with the new version while maintaining service availability. Because the database schema migration has already been applied, the application can safely consume:

• Newly created tables
• Updated columns
• Additional indexes
• New constraints
• Modified database structures

This sequencing helps eliminate compatibility issues that commonly occur when application and database deployments are managed separately.

Automated Rollback for Safer Releases

One of the most valuable aspects of a unified deployment pipeline is coordinated rollback. If verification identifies an issue, the stage can automatically trigger rollback actions.

failureStrategies:
  - onFailure:
      errors:
        - AllErrors
      action:
        type: StageRollback

The rollback workflow executes the Kubernetes rollback step:

rollbackSteps:
  - step:
      type: K8sRollingRollback
      name: Rollback Rollout Deployment

This enables teams to quickly restore the previous application version and minimize production impact. Combined with database deployment visibility and rollback strategies, organizations can significantly reduce deployment risk and improve recovery times.

Benefits of Combining Continuous Delivery and Database DevOps

• Faster Release Velocity: Database and application changes move through a single automated workflow without waiting for separate deployment windows.
• Safer Database Schema Migrations: Version-controlled database schema migrations help ensure consistency across environments.
• Improved Visibility: Teams gain centralized insight into deployments, migration history, and release status.
• Better Governance: Approval workflows, policies, and compliance requirements can be enforced directly within deployment pipelines.
• Reduced Deployment Risk: Verification and rollback become built-in parts of every release.
• Stronger Collaboration: Developers, platform engineers, and database teams work from the same deployment process rather than maintaining separate release workflows.

Bringing Database Schema Migration into Modern Continuous Delivery

Database schema migration should not be treated as a separate operational activity. Modern software delivery requires application code and database changes to move together through a secure, automated, and governed deployment process. Harness Database DevOps enables teams to:

• Automate database schema migrations
• Integrate database deployments into CI/CD pipelines
• Manage version-controlled database changes
• Apply governance and compliance controls
• Support rollback and recovery workflows
• Deploy applications and databases together through a unified pipeline

By combining Harness Continuous Delivery and Harness Database DevOps, organizations can streamline releases while reducing deployment risk and improving operational efficiency.

Conclusion

Application releases and database schema migrations are two parts of the same deployment. Managing them separately creates unnecessary complexity, increases risk, and slows delivery.

By orchestrating database schema migrations, Kubernetes deployments, verification, and rollback within a single pipeline, teams can build a more reliable and efficient release process. Harness Database DevOps and Continuous Delivery provide the foundation for modern software delivery, enabling organizations to deploy applications and database changes together with greater confidence, visibility, and control. Explore how Harness Database DevOps can transform your delivery process today.

• To ensure releases are safe, scalable, and compliant, Feature Flags should be built into CI/CD and GitOps workflows with the same level of governance, policy, and automation as code deployments.
• AI-driven automation and smart pipelines remove manual work by generating, verifying, and managing Feature Flag workflows across many services. This speeds up delivery while keeping enterprise safeguards in place.
• Strong Policy as Code, centralized visibility, and automated lifecycle management turn Feature Flags from possible governance gaps into controlled assets. This helps reduce risk and maintain compliance at an enterprise level.

Engineering teams often deploy code much faster than they can safely release new features to users. This gap can create risks if releases skip testing, approvals, or gradual rollouts. Feature flags help by separating deployment from release, so you can ship code continuously and control which features users see through configuration.

The solution isn't just adding flags to your code. The key is treating your Feature Flag implementation as part of your CI/CD system, not just application code. When flags flow through GitOps workflows with policy governance, automated verification, and rollback capabilities, teams can accelerate delivery across hundreds of services without creating bespoke pipelines. This approach transforms flags from tactical tools into enterprise-grade release orchestration components that maintain compliance while enabling developer velocity.

See how Harness Continuous Delivery & GitOps provides AI-powered automation and centralized governance to implement Feature Flags at scale across your entire deployment ecosystem.

How to Implement Feature Flags in Enterprise CI/CD Pipelines

Managing feature rollouts across more than 200 microservices without standard processes can quickly lead to pipeline sprawl in enterprise CI/CD environments. The answer is to use Feature Flags in enterprise CI/CD pipelines with the same strict governance as production code deployments. This organized approach removes the need for custom pipelines and keeps enterprise-level control.

Establish Governance and Policy as Code Foundation

Set clear categories for flags before teams start making toggles. For example, use release flags for deployment gates, operational flags for circuit breakers, and experiment flags for A/B testing. Make sure each category has defined ownership, lifecycle rules, and review steps.

Set up policies to block unauthorized changes to production flags and to enforce naming rules, including service ownership and expiration dates. This governance helps prevent technical debt from unmanaged flags and makes future operations simpler.

Instrument Services and Integrate with GitOps Workflows

Install Feature Flag SDKs in your services and make sure flag changes go through your GitOps processes, triggering the same reviews as application updates. Set up your deployment pipelines so flag updates are treated like deployment events, starting canary releases and health checks.

This setup makes sure flag changes get the right level of review without slowing down deployments. Link flag states to your observability tools, so metrics include toggle information, making it easier to troubleshoot quickly.

An enterprise platform like Harness Feature Management & Experimentation centralizes these flags and audits across services.

Automate Production Verification and Cleanup Processes

Set up automated rollback systems that watch performance metrics during flag rollouts and revert changes if problems appear. Use time-to-live policies for temporary toggles and automate their cleanup.

Plan regular audits of your flags to create removal tasks and pull requests for outdated configurations. This organized lifecycle management helps prevent configuration drift, which can slow down deployments and make debugging harder.

Security and Governance Best Practices for Feature Flags

Feature flags require robust governance to meet regulatory requirements and maintain compliance across enterprise environments. Implementing best practices for secure Feature Flag implementation in DevOps workflows becomes even more important when managing hundreds of microservices with strict audit requirements.

• Enforce role-based access controls with environment-specific permissions and mandatory approvals for production flags
• Encrypt flag configurations at rest and in transit, treating targeting rules as sensitive production data
• Implement Policy as Code governance using OPA to automatically enforce naming conventions and approval workflows across all services
• Set automatic expiration dates on temporary flags to prevent technical debt and reduce compliance exposure
• Enable complete audit trails with immutable logs that track every flag change and user action

These security steps turn Feature Flags from possible governance risks into controlled assets that make deployments safer at scale. With the right governance, you can automate flag workflows using AI-powered pipelines that keep things secure and speed up delivery across all your services.

Automating Feature Flag Workflows with AI-Driven Continuous Delivery

Context-aware AI changes how teams set up Feature Flag workflows by automatically building pipelines with canary deployments, approval gates, and verification steps. Rather than spending days making custom setups for each service, AI reviews your current templates, connectors, and policies to create ready-to-use pipelines in minutes.

This approach answers how Feature Flag implementation can be automated using AI-driven continuous delivery tools by removing manual scripting while maintaining enterprise governance through flexible templates and OPA policies.

Beyond pipeline generation, intelligent verification closes the loop between flag changes and production health by automatically connecting feature evaluations to observability data from Datadog, CloudWatch, or other monitoring systems.

When flags are switched, AI-powered checks automatically link flag changes to performance data and system logs to spot problems right away. This setup allows for quick, automated rollbacks, making Feature Flags a strong tool for protecting production without manual work.

Automated flag lifecycle management helps avoid technical debt by finding old flags and creating cleanup tasks as releases move to full rollout. AI spots flags that haven't changed for over 30 days, checks them against deployment history, and creates removal pull requests to keep your code clean.

This intelligent approach keeps flag configurations lean and compliant through Harness Continuous Delivery, reducing the operational burden of managing hundreds of feature toggles across enterprise-scale deployments while meeting audit requirements for configuration drift.

Ship Faster with Guardrails—Feature Flags + Harness CD & GitOps

Feature flags work well at enterprise scale when you manage them through your CI/CD pipelines with the same governance as code deployments. By integrating flags with GitOps workflows, policies, and automated checks, you avoid building custom pipelines for hundreds of services.

To make this work at scale, set up standard processes that automatically apply flag governance. Use centralized templates and Policy as Code enforcement as best practices. AI-powered checks can spot performance issues and trigger rollbacks without manual effort.

Want to speed up safe releases while keeping enterprise governance? Harness Continuous Delivery & GitOps brings together Feature Flags and AI-driven continuous delivery to cut down on deployment work and lower risk throughout your software delivery process.

What is a DevOps toolchain?

A DevOps toolchain is the connected set of tools your team uses to move software from code to production: source control, CI/CD, security testing, IaC, and observability. DORA 2025 finds that elite teams deploy 182x more frequently than low performers; the difference is not more tools but fewer, better-integrated ones with shared governance.

‍
A new engineer joins a team and asks what is a DevOps toolchain. What comes back is a 22-line inventory: a source host, two CI systems, an IaC engine, a registry, three scanners, a deployment tool, a couple of dashboards, and nobody who can fully explain how they all connect. That inventory is the team's DevOps toolchain, and its length is often mistaken for its strength.

A DevOps toolchain is the set of tools spanning the software delivery lifecycle (source, build, test, security, deployment, and operations) that a team assembles to move software from code to production safely and reliably. A useful DevOps toolchain covers every stage with as few disconnected tools as possible. The goal is not the longest list. It is the smallest unified stack that lets teams ship faster and safer.

Why isn't the longest DevOps toolchain the best one?

Every team needs certain tools: source control, CI, CD, security testing, observability. But the instinct to add a specialised tool for every edge case is what creates sprawl. A team running GitHub, Jenkins, CircleCI, ArgoCD, Terraform, Atlantis, LaunchDarkly, Snyk, Datadog, and PagerDuty is not well-equipped. It is fragmented. Each tool owns its logs, its access model, and its failure modes.

The real cost of a long DevOps toolchain is not the tool licenses. It is the integration toil, the governance gaps, the constant context-switching, and the developer time spent chasing approvals instead of shipping. Harness research (State of AI in Software Engineering 2025) shows 71% of teams say context-switching between tools drains productivity, and 73% of engineering leaders report barely any teams have standardized golden paths.

A DevOps toolchain that scales is not the one with the most tools. It is the one where adding the hundredth team costs about what adding the tenth did, because the path is standardized and governed centrally, not rebuilt each time.

What DevOps automation tools, CI/CD automation, and devops toolchain list do you need?

A functional DevOps toolchain covers these stages. Each stage has multiple options, but the principle is the same: choose DevOps automation tools that integrate well, then consolidate the integration points.

The categories matter less than the integration. A CI tool that shares a policy layer with your CD and GitOps platform and security testing stages is more valuable than three separate tools with no shared context. CI/CD automation is the backbone, but the value compounds when security, cost, and reliability share the same governance layer. The Internal Developer Portal is what surfaces these as golden paths developers self-serve on, rather than ticket queues they wait on.

How does AI change your DevOps toolchain requirements?

AI coding assistants changed the production rate. Developers now produce code significantly faster, and organizations ship faster as a result. But the DevOps toolchain that has to test, secure, and ship that code did not accelerate at the same rate. That mismatch is the AI Velocity Paradox: the build queue grows, the deployment queue grows, the surface area for security scanning expands.

A DevOps toolchain that worked fine for 50 commits a day falls apart at 500. The solution is not to add more tools. It is to consolidate the ones you have so governance, verification, and rollback stay consistent as volume increases.

Teams using AI coding tools most heavily have the highest remediation rates (22%) and longest mean time to recovery (7.6 hours), according to the Harness 2026 State of DevOps Modernization. That is not a tool problem. It is a governance and integration problem.

How Harness simplifies DevOps toolchain consolidation

The challenge

Platform teams are asked to give developers fast, self-service delivery while maintaining governance and reliability. As AI accelerates code output and tools accumulate, the after-code stages (testing, securing, deploying, operating) fragment across products with no shared context or governance. The platform team ends up maintaining integration seams instead of improving delivery.

The approach

Harness is the AI-native Software Delivery Platform that automates and governs everything after code is written. The Software Delivery Knowledge Graph ties each build, deployment, and security event back to the service and commit it came from. On that foundation sit the after-code modules: Continuous Delivery and GitOps, Continuous Integration, the Internal Developer Portal, Infrastructure as Code Management, Application Security Testing, AI SRE, and Cloud and AI Cost Management. Each inherits shared access control, governance, and a single audit trail. Developer-friendly guardrails.

The outcome

Consolidating the after-code stages onto one governed platform reduces governance gaps, accelerates remediation, and cuts the developer toil that sprawl creates. Teams can ship faster and safer as they scale, and adding new teams or services does not require rebuilding the entire DevOps toolchain. See how teams have simplified their toolchains.

How have teams simplified their DevOps toolchains?

Two teams, two different sprawl problems, one pattern: consolidation returns engineering time to the work that requires judgment.

How did Ancestry go from 80 Jenkins instances to governed CI/CD at scale?

Ancestry managed over 80 distinct Jenkins instances: one per team, with no central governance. Consolidating onto Harness let them apply a single pipeline change across all teams instead of editing each instance by hand. The result: an 80-to-1 reduction in pipeline implementation effort, 50% fewer deployment-caused outages, and a 78% reduction in systems-onboarding toil.

“Harness now enables Ancestry to implement new features once and automatically extend those across every pipeline, representing an 80-to-1 reduction in developer effort.”

Ken Angell, Principal Architect, Ancestry

Source: Ancestry adds consistency and governance to cut downtime

How did a UK software company cut manual DevOps tickets by 80 to 90%?

A UK-based software company relied on manual, ticket-based access requests for GitHub, Copilot, and AWS, creating a continuous bottleneck for a small DevOps team. Adopting the Harness Internal Developer Portal turned that manual overhead into self-service workflows with guardrails. Priority projects onboarded in weeks instead of months; the DevOps team refocused on higher-value work.

“We have reduced tickets by 80 to 90%. What took a full-time team to manage manually is now done automatically with appropriate guardrails.”

Principal DevOps Architect, enterprise software company

Source: Enterprise software company reduces DevOps tickets by 80%

Consolidate the DevOps toolchain: CI CD automation and beyond

The best DevOps toolchain is not the longest devops toolchain list. It is the one where fewer, well-integrated DevOps automation tools replace fragmented point solutions, and where adding the hundredth team costs about what adding the tenth did. Start from the governance gaps: find the stages where your audit trails break, where approvals wait on a human, where a deploy needs someone watching a dashboard. Those are the integration seams worth removing.

A unified platform covering the after-code lifecycle with shared governance, golden paths, and AI-native automation is how teams absorb AI-generated code at machine speed without losing control of what ships. 

See how Harness brings the full after-code lifecycle onto one platform.

What are DevOps technologies?

DevOps technologies are the infrastructure that enables teams to ship code frequently, safely, and reliably. They automate repetitive work, provide visibility into system behavior, enforce governance, and give teams the confidence to deploy multiple times per day without breaking production. The best DevOps technologies aren't the fanciest, they're the ones that actually reduce toil and risk.

How has the DevOps tool stack and technology landscape changed?

2015: Point tools dominated. Teams picked a specialised tool for each stage: Jenkins for CI, Ansible for infrastructure, Splunk for logs, PagerDuty for incidents. Each tool had its own interface, permissions model, and failure modes. Teams owned 8 to 12 tools, context-switching was constant, and integration was manual.

2020: Consolidation began. Cloud-native tools emerged (Kubernetes, GitHub Actions, ArgoCD). Teams started asking: can we reduce tools instead of adding more? The problem: consolidation is hard, tools do not integrate cleanly, and switching costs are high.

2026: Platforms emerge. The trend accelerates. Teams adopt unified platforms that handle CI, CD, infrastructure, security, and observability in one place. The shift is economic: fragmentation costs more in toil and governance gaps than a unified platform costs in licensing.

The core shift: DevOps technologies used to be evaluated individually. Now they are evaluated as ecosystems, and the devops tool stack you build is as important as any individual tool in it.

How AI is reshaping DevOps technologies and the delivery lifecycle

AI coding assistants are changing the math. According to Harness research, 63% of organizations use AI tools like Copilot or Claude to write code. Code arrives faster, but it is also different: AI-generated code has different patterns, edge cases, and failure modes than handwritten code.

72% of organizations have experienced at least one production incident from AI-generated code. That is the AI Velocity Paradox. DevOps technologies must evolve to keep up. The testing, security scanning, and deployment gates that worked for handwritten code may not work for machine-generated code at scale.

DevOps technologies in the AI era need to focus on automated governance, fast rollback, and continuous observability. You cannot safely ship AI code without automated testing that catches AI-specific failure modes, security scanning that covers generated code patterns, deployment gates fast enough to match code volume, and rollback strategies that revert instantly.

What are the most important DevOps technologies and devops engineer tools to invest in?

Not all DevOps technologies are equally important. The devops practices and tools that earn a place in your stack cluster around three pillars.

• Continuous Integration and Delivery (CI/CD). This is where code gets tested and deployed. Invest in platforms that can scale with AI-generated code volume.
• Infrastructure as Code Management. Define infrastructure in code so it is version-controlled, auditable, and repeatable.
• Observability and AI SRE. You cannot manage what you cannot see. Real-time visibility into application performance, errors, and user impact is critical as code volume increases.
• Security testing. Embed scanning into the pipeline rather than bolting it on after. DevOps engineer tools that enforce policy-as-code at every stage prevent the governance gaps that incident postmortems trace back to.

DevOps best practices: evaluating devops practices and tools for your stack

Choosing well is itself one of the core DevOps best practices: the strongest stacks are built on a few deliberate decisions, not an ever-growing pile of tools. When evaluating DevOps technologies, ask five questions.

• Does it reduce toil? Can it automate the repetitive work that is consuming engineering time? If not, it is not worth the cost.
• Does it integrate with your existing stack? Can it work alongside the tools you already use, or does it require ripping out and replacing everything?
• Can it scale? Can it handle 10x more deployments, services, or teams without requiring a complete overhaul?
• Does it enforce governance? Can you apply policy-as-code, audit access, and maintain control across teams without manual coordination?
• What is the total cost of ownership? Factor in licensing, integration, training, and the fragmentation cost of choosing point tools.
  

How Harness approaches the DevOps technology strategy

The challenge

DevOps technology sprawl is real. Teams run 8 to 10 AI tools plus another 20 or more for the delivery pipeline. Each tool has its own logs, permissions, and failure modes. That fragmentation slows everything down: context-switching drains productivity, governance gaps create risk, and incident response is painful because no single tool has the full picture.

The approach

Harness consolidates the delivery platform with unified products: Continuous Integration, Continuous Delivery and GitOps, Infrastructure as Code Management, the Internal Developer Portal, Application Security Testing, AI SRE, and AI-native delivery. The unifying mechanism is the Software Delivery Knowledge Graph: an intelligence layer that connects code, commits, deployments, and outcomes into one source of truth.

The outcome

Teams consolidate their DevOps technology stack, reduce tool sprawl, lower governance risk, and operate at scale. The average team reclaims 10–15 hours per week previously lost to context-switching and integration work.

How have teams modernized their DevOps tool stack?

The shift from fragmented tools to a unified platform shows up in delivery metrics, not just in tooling inventories.

How did Vivun achieve a 300% improvement in DevOps engineer efficiency?

A SaaS company struggled with fragmented DevOps technologies. Each product feature required manual coordination across CI, CD, and infrastructure tools; engineers spent more time integrating than delivering. Consolidating onto Harness transformed the devops practices and tools the team used daily.

“Harness has been the catalyst for faster delivery and more DevOps engineers shipping higher-quality products every day.”

Jon Call, Engineering Manager for SRE, Vivun

Source: Vivun scales DevOps with Harness

How did Citi cut deployment lead time from days to 7 minutes?

A global financial services company with 20,000 or more engineers needed DevOps technologies that could scale and govern delivery across a heavily regulated environment. Their legacy approach was slow and fragile. Moving onto Harness CD reduced deployment lead time from days to minutes.

“Harness CD let us release each change within minutes of a pull request being merged.”

Stefanos Piperoglou, Technical Program Manager, Citi

Source: Citi improves software delivery performance with Harness CD

Different industries, same pattern: when DevOps technologies consolidate onto one governed platform, delivery gets faster and governance gets tighter at the same time.

Invest in the ecosystem, not just the tool

DevOps technologies in 2026 are not evaluated in isolation. The question is whether they reduce toil, integrate cleanly, scale without re-engineering, and enforce governance automatically. That is a different question from whether a tool is powerful. Many powerful tools fail this test because they add integration seams faster than they remove them.

The teams pulling ahead are not using the most tools. They are using the fewest well-integrated ones, built on shared governance, shared data, and shared audit trails. See how Harness brings the full after-code lifecycle onto one AI-native platform.

What are DevOps solutions?

DevOps solutions are the tools and platforms that help teams build, test, secure, deploy, monitor, and manage software throughout the software delivery lifecycle. While DevOps is often associated with CI/CD, modern DevOps software supports a much broader set of capabilities, including infrastructure automation, security, observability, testing, and developer self-service.

Organizations can adopt individual point tools for specific functions or use integrated DevOps platforms that bring multiple capabilities together. Point tools typically focus on a single capability, while integrated DevOps platforms combine multiple functions into a unified experience.

Quick Facts

Engineering teams have more DevOps solutions to choose from than ever before. CI/CD platforms, infrastructure automation tools, security scanners, observability platforms, and developer productivity solutions all promise faster software delivery. Yet for many organizations, adding tools has not necessarily made delivery simpler.

As software delivery environments grow, so does the operational burden of managing integrations, permissions, workflows, and governance across multiple systems. By 2027, most organizations will shift from multiple point solutions to unified platforms to streamline application delivery, reversing where the majority sat in 2023.

Choosing a DevOps stack is no longer just a tooling decision. It is an architectural decision that affects developer productivity, operational efficiency, governance, and the ability to scale software delivery over time. This guide explores the different types of DevOps solutions and the criteria teams should use when evaluating the right stack for their needs.

What to look for in DevOps software and what are DevOps tools worth keeping?

The capabilities listed above do not carry equal weight. Most teams already have access to CI/CD tools, security scanners, monitoring platforms, and infrastructure automation frameworks. The real question is whether those capabilities work together to improve software delivery.

When evaluating DevOps solutions, focus on six areas:

Beyond features, consider the long-term operational impact of each option. Integration maintenance, onboarding effort, licensing costs, and platform administration all contribute to the total cost of ownership. A tool that solves one problem today can create additional complexity as teams, applications, and delivery requirements grow.

Quick Tip: The lowest-cost DevOps tool isn't always the most cost-effective option. As teams scale, integration, maintenance, platform administration, and operational overhead can outweigh initial licensing savings.

Having the right capabilities is only part of the decision. Teams must also determine whether those capabilities should come from a unified platform or a collection of specialized devops software tools.

Types of DevOps solutions for modern software delivery in 2026

Most organizations choose between two approaches: adopting a unified DevOps platform or assembling a best-of-breed toolchain. The right choice depends on factors such as team size, operational complexity, compliance requirements, and internal engineering resources.

The same trade-offs apply when evaluating open source and commercial solutions. Open source tools often provide flexibility and community-driven innovation but may require additional expertise to deploy, integrate, and maintain. Commercial platforms typically offer enterprise support, built-in integrations, and streamlined administration in exchange for licensing costs.

Deployment models also influence tool selection. Cloud-native solutions are often preferred for scalability and faster adoption, while on-premise deployments remain common in highly regulated industries with strict security, compliance, or data residency requirements.

The best DevOps solution is not defined by a single category. It depends on how well the chosen approach aligns with your team's delivery model, governance needs, and long-term operational strategy. The same DevOps approach rarely works equally well across organizations. A startup focused on shipping quickly faces a different set of constraints than an enterprise managing hundreds of developers, compliance requirements, and complex delivery pipelines.

How do you evaluate the best DevOps tools for your team?

The same DevOps solution can be a great fit for one organization and a poor fit for another. Team size, delivery complexity, and operational requirements often have a greater impact on tool selection than feature lists.

Regardless of company size, engineering leaders should evaluate every DevOps solution against a few practical questions:

• Will this reduce operational complexity or add to it?
• How much effort will be required to onboard teams and maintain integrations?
• Can it scale alongside our applications, teams, and delivery processes?
• What are the long-term costs, including licensing, administration, and platform maintenance?

Vendor lock-in should also be part of the evaluation process. The deeper a tool becomes embedded in deployment pipelines, security controls, and developer workflows, the more difficult and costly it becomes to replace. Many DevOps initiatives run into trouble not because teams chose the wrong solution category, but because critical considerations such as workflow design, governance, and developer adoption were overlooked during implementation.

Common DevOps solution mistakes to avoid

Even well-intentioned DevOps initiatives can create new challenges when tooling decisions are made in isolation.

• Adding tools to solve every new problem. More tools often mean more integrations, handoffs, and maintenance overhead. Fix: consolidate capabilities where possible and evaluate the operational cost of every addition.
• Treating developer experience as an afterthought. Complex workflows and fragmented tooling slow adoption and create friction for engineering teams. Fix: prioritize solutions that simplify day-to-day development and deployment tasks.
• Leaving governance until later. Retrofitting security, compliance, and access controls is often more difficult than building them into delivery workflows from the start. Fix: evaluate governance requirements alongside functionality.
• Selecting tools before defining delivery workflows. Technology rarely fixes unclear processes. Teams that start with tooling often end up redesigning workflows later. Fix: establish how software should move from development to production before evaluating solutions.

Reducing operational overhead is one reason many organizations are rethinking fragmented DevOps toolchains in favor of platform-based approaches.

How Harness fits into your DevOps stack

As software delivery becomes more complex, many organizations are looking for ways to improve engineering efficiency without adding operational overhead. DORA research (State of AI-assisted Software Development 2025) finds that software delivery performance predicts organizational performance and employee well-being, reinforcing the need for tools that help teams deliver software reliably and at scale.

Harness brings key software delivery capabilities together in a unified, AI-powered platform. Teams can automate build and test workflows with Harness CI, streamline deployments using Harness CD, and gain visibility into engineering productivity and delivery metrics through AI DLC Insights.

Cost efficiency is becoming equally important. According to the FinOps Foundation, 45% of organizations spending more than $100 million annually on cloud report that AI and machine learning are having a rapidly increasing impact on their FinOps practices. Harness Cloud & AI Cost Management (CACM) helps teams understand, optimize, and govern cloud spending alongside their software delivery workflows, reducing the need to manage disconnected tools across the engineering ecosystem.

How do Harness DevOps solutions perform in practice?

Organizations evaluating DevOps solutions often face the same challenge: balancing delivery speed, governance, visibility, and operational overhead. The following examples show how different teams approached those challenges.

How did Ancestry replace 80-plus Jenkins instances with one governed pipeline?

Ancestry managed software delivery across more than 80 Jenkins instances, with each team following a different deployment process and governance practice. After adopting Harness CI/CD, the company onboarded 350 systems in its first year, increased deployment frequency 3x, and achieved an 80-to-1 reduction in the effort needed to roll a change out across every pipeline.

“Harness now empowers Ancestry to implement new features once and then automatically extend those across every pipeline, representing an 80-to-1 reduction in developer effort.”

Ken Angell, Principal Architect, Ancestry

Source: Ancestry adds consistency and governance to cut downtime

How did United Airlines put governance in developers' hands without slowing delivery?

United Airlines needed stronger governance across software delivery without slowing development teams. Choosing Harness for CI and CD let the airline shift security and governance left, giving developers self-service deployment within guardrails instead of waiting on manual review. United reported 75% efficiency gains and cut CI build times for one application from 22 minutes to under 5.

“By choosing Harness for CI and CD, we were able to give the governance policies to the developers and create the guardrails we needed. Harness gives us a platform rather than just a DevOps tool.”

Ratna Devarapalli, Director of IT, Architecture, Platform Engineering and DevOps, United Airlines

Source: United Airlines accelerates deployments with Harness

How did Tyler Technologies save $1.2 million a year on cloud costs?

Tyler Technologies, the largest SaaS vendor solely focused on the U.S. public sector, ran client test environments around the clock even when most sat idle outside business hours. Reorganizing its cloud estate by client time zone and activity pattern and applying Harness Cloud Cost Management's AutoStopping let Tyler power down idle environments automatically. The result: $1.2 million in annualized cloud cost savings.

“Cloud AutoStopping opened up new possibilities for cloud cost management. We saw how reorganizing our deployments by geography, function, and use patterns could unlock game-changing savings.”

Chris Camire, Senior Manager of Technical Services, Tyler Technologies

Source: Tyler Technologies reaches $1.2M annualized cost savings with Harness Cloud Cost Management

Choose the DevOps solution that fits your delivery model, not the longest feature list

The capabilities matter less than how well they fit together. A long feature list does not tell you whether a tool will reduce operational complexity or add to it, and the gap between those two outcomes is where most DevOps initiatives succeed or stall.

Map your own delivery workflow first, then evaluate DevOps solutions against integration, governance, scalability, and total cost, not a checklist of capabilities. 

See how Harness brings CI, CD, security, and cost management onto one AI-powered platform.

• Structured, conditional debugging, using verbosity controls, targeted variable inspection, and context-aware output, dramatically reduces troubleshooting time and noise in Ansible playbooks.
• Integrating best practices such as reusable debug roles, failure taxonomies, and CI/CD-friendly log formatting enables teams to automate root cause analysis and artifact collection, making incidents easier to resolve and less likely to recur.
• Embedding these debugging patterns into your delivery pipelines with platforms like Harness unlocks AI-powered verification, automated rollbacks, and scalable governance, transforming manual debugging insights into proactive, automated deployment safety nets.

Infrastructure as Code (IaC) has transformed how teams manage environments, but let’s be honest: when something breaks, debugging can feel like searching for a needle in a YAML haystack.

If you’re working with Ansible, you already know its power: agentless automation, declarative playbooks, and consistent deployments. But even the most elegant playbooks can fail due to syntax issues, variable conflicts, or unexpected runtime behavior.

That’s where a structured debugging approach and modern platforms like Harness come in. With solutions like Harness Infrastructure as Code Management, teams gain visibility, governance, and control over IaC workflows at scale, enabling faster, more reliable troubleshooting.

Why Debugging Ansible Playbooks Matters

Ansible is designed for simplicity, but real-world environments are anything but simple. Debugging is essential because:

• Playbooks can fail silently or behave unexpectedly
• Variables and templates can produce inconsistent results
• Infrastructure differences across environments can cause drift
• Dependencies between tasks and roles can create hidden issues

Common challenges include variable interpolation problems, connection errors, and inconsistent execution across hosts.

Without proper debugging, these issues can slow down deployments, introduce risk, and waste engineering time.

How Ansible Executes Playbooks

Before debugging, you need to understand how Ansible works:

• A playbook contains plays
• Each play targets hosts
• Plays include tasks
• Tasks execute modules

When something fails, it’s crucial to pinpoint where in this hierarchy the issue occurs. Understanding execution flow helps you isolate problems faster and avoid guesswork.

How to Troubleshoot and Debug Ansible Playbooks

Step 1: Start with a Syntax Check

The fastest way to catch issues? Validate your YAML before execution.

ansible-playbook --syntax-check playbook.yml

This catches:

• YAML formatting errors
• Missing colons or indentation issues
• Invalid structure

Syntax errors are one of the most common causes of failure, so never skip this step.

Step 2: Increase Verbosity for More Insight

Ansible provides built-in verbosity flags that reveal what’s happening under the hood:

ansible-playbook playbook.yml -v
ansible-playbook playbook.yml -vv
ansible-playbook playbook.yml -vvv
ansible-playbook playbook.yml -vvvv

Each level gives you deeper visibility:

• -v: Basic task info
• -vv: Includes variable values
• -vvv: Task-level debugging
• -vvvv: Connection-level details

This is often the quickest way to identify where things go wrong.

Step 3: Use the Ansible Debug Module

The debug module is your best friend when troubleshooting.

It allows you to:

• Print variable values
• Inspect task outputs
• Track execution flow

Example:

- name: Debug variable
  debug:
    var: my_variable

You can also display custom messages:

- name: Print message
  debug:
    msg: "Deployment started"

This helps you verify that variables are set correctly and tasks are executing as expected.

Step 4: Run in Check Mode (Dry Run)

Want to test changes without impacting systems?

Use check mode:

ansible-playbook playbook.yml --check

This simulates execution and shows what would change without actually applying it.

It’s ideal for:

• Testing updates safely
• Validating logic
• Preventing unintended changes

Step 5: Use the Ansible Playbook Debugger

Ansible includes an interactive debugger that triggers when tasks fail.

You can enable it like this:

- name: Example task
  command: /bin/false
  debugger: on_failed

When a task fails, the debugger allows you to:

• Inspect variables
• Modify arguments
• Re-run tasks

This eliminates the need to rerun the entire playbook repeatedly.

Step 6: Validate Variables and Templates

Many issues stem from incorrect variables or templating.

Common problems include:

• Undefined variables
• Incorrect variable precedence
• Jinja2 template errors

Use debug statements to inspect variables:

- debug:
    msg: "{{ my_variable }}"

Or check if variables exist:

when: my_variable is defined

Understanding variable behavior is critical for reliable playbooks.

Step 7: Inspect Registered Variables

Registered variables capture task results, which can be incredibly useful.

Example:

- name: Run command
  command: ls
  register: result

- debug:
    var: result

This shows:

• Command output
• Exit status
• Execution metadata

It’s especially useful when debugging conditional logic or failures.

Step 8: Troubleshoot Connection Issues

Connection problems are another common culprit.

To debug:

• Use -vvvv for connection logs
• Verify SSH access
• Check inventory configuration

You can also enable:

ANSIBLE_KEEP_REMOTE_FILES=1

This keeps temporary scripts on remote machines for inspection.

Step 9: Break Down Complex Playbooks

Large playbooks are harder to debug.

Best practice:

• Split playbooks into smaller roles
• Test individual components
• Run tasks step-by-step

You can use:

ansible-playbook playbook.yml --step

This lets you execute tasks interactively, one at a time.

Step 10: Use Logging and Monitoring

Logging is essential for long-term debugging.

You can configure logging in Ansible.cfg:

[defaults]
log_path = /var/log/ansible.log

Logs help you:

• Track execution history
• Identify recurring issues
• Debug production failures

Step 11: Apply Conditional Debugging

Sometimes, you only want debug output under certain conditions.

Example:

- debug:
    msg: "Variable is set"
  when: my_variable is defined

This reduces noise while still providing useful insights.

Step 12: Common Errors and How to Fix Them

Let’s look at frequent issues:

1. YAML Syntax Errors

• Cause: Incorrect indentation
• Fix: Use linting tools and syntax checks

2. Undefined Variables

• Cause: Missing or misspelled variables
• Fix: Use debug and validation

3. Task Failures

• Cause: Incorrect module usage
• Fix: Check module documentation and outputs

4. Connection Failures

• Cause: SSH or inventory issues
• Fix: Verify credentials and host access

5. Idempotency Issues

• Cause: Tasks not designed to be repeatable
• Fix: Use proper module parameters

Step 13: Build a Systematic Debugging Workflow

The most effective teams follow a structured approach:

1. Run syntax check
2. Execute with verbosity
3. Add debug statements
4. Validate variables
5. Use check mode
6. Inspect logs
7. Use a debugger for failures

This ensures you move from simple checks to deeper analysis without wasting time.

How Harness Improves Ansible Debugging at Scale

While native Ansible tools are powerful, they can become difficult to manage at scale, especially across multiple environments and teams.

That’s where Harness Infrastructure as Code Management comes in.

With Harness, teams can:

• Centralize IaC workflows
• Visualize deployments and failures
• Enforce governance and compliance
• Detect drift across environments
• Debug faster with unified insights

Instead of chasing errors across logs and CLI outputs, Harness provides a single pane of glass for managing and troubleshooting infrastructure.

Best Practices for Debugging Ansible Playbooks

To avoid recurring issues, follow these best practices:

• Keep playbooks simple and modular
• Use descriptive task names
• Validate inputs early
• Leverage check mode before deployment
• Use version control for playbooks
• Add debug statements during development
• Monitor logs consistently

Consistency and structure are key to reliable automation.

Move From Guessing To Knowing, Then Automate It

Structured Ansible debug and delivery practices transform reactive firefighting into proactive problem-solving. When you standardize verbosity levels, conditional output, and failure analysis, you cut mean time to resolution and stop scrolling through endless logs hunting for clues.

Those same debugging patterns that help you isolate failures manually become the intelligence that drives automated pipeline decisions. Smart platforms use your codified failure conditions, rollback triggers, and health checks to make deployment decisions without human intervention. Teams that systematize their debugging insights can focus on building features instead of babysitting deployments.

Ready to turn those debugging skills into automated safety nets? Harness Infrastructure as Code Management delivers AI-powered verification, automatic rollbacks, and GitOps workflows that eliminate the guesswork from production deployments.

FAQ: Fast Answers To Common Ansible Debug Questions

These five questions address the debugging bottlenecks that turn 5-minute fixes into hour-long investigations. Each answer provides tested patterns that cut time-to-resolution.

How do I choose between -vv and -vvvv without flooding logs?

Use -vv for task-level details and connection info. Reserve -vvv for module arguments and package manager chatter. Use -vvvv only when you need SSH transport debugging. In CI, pair verbosity with --limit to constrain output and keep log budgets manageable.

What's the safest way to print secrets without exposing them in CI logs?

Never use debug: var= with secret variables directly. Instead, print only non-sensitive metadata, such as key names or lengths. Use Ansible Vault for encryption and use your CI platform's secret management. Harness handles secret injection safely in pipeline runs.

How do I debug a task that only fails on one host in a 59-host inventory?

Use --limit hostname to isolate the problematic host. Enable the task debugger with ANSIBLE_ENABLE_TASK_DEBUGGER=True for interactive inspection. Compare gathered facts between working and failing hosts to identify configuration drift or missing dependencies.

Why does my changed_when always show changed even when nothing updates?

Shell and command tasks default to changed: true regardless of whether there are actual changes. Define explicit changed_when conditions, such as changed_when: result.rc == 0 and 'updated' in result. stdout. Use --check and --diff modes to preview changes before execution.

How do I persist and attach Ansible logs and diffs as CI artifacts for PRs?

Structure output with JSON formatting and redirect to files. Archive stdout, stderr, and diff outputs as build artifacts. Harness pipelines can capture these automatically and attach them to PR checks. Harness CD extends this with AI verification and automated rollback based on deployment artifacts.

What is a DevOps platform?

A DevOps platform is an integrated software delivery system that manages the entire software development lifecycle (SDLC)—from source code and continuous integration (CI) to deployment, security, infrastructure, and operations. Unlike standalone DevOps tools that solve individual problems, a DevOps platform connects teams, workflows, and delivery processes in a single environment, providing shared automation, governance, and visibility.

A DevOps platform is becoming the standard answer to a gap that keeps widening: software development is accelerating, but software delivery is not keeping pace. AI is helping engineering teams write code faster, yet moving that code safely from commit to production still depends on build pipelines, security checks, deployment workflows, governance, and cross-team collaboration.

This gap is becoming more apparent as organizations adopt AI. The 2025 DORA State of AI-assisted Software Development report finds that AI amplifies an organization's existing strengths and weaknesses. Teams see the greatest benefits not from AI alone, but from strong internal platforms, well-defined engineering workflows, and effective collaboration.

That is why organizations are rethinking fragmented DevOps toolchains. Instead of relying on disconnected tools stitched together with custom integrations, many are adopting DevOps platforms that unify software delivery into a single system. The result is faster releases, stronger governance, and better visibility across the software development lifecycle.

In this guide, you will learn what a DevOps platform is, how it differs from a standalone DevOps pipeline, and what capabilities to look for when evaluating one for your organization.

What is the difference between a DevOps pipeline and a DevOps platform?

A DevOps pipeline is a single automated workflow, such as building and deploying an application. A DevOps platform manages and orchestrates multiple pipelines while connecting the people, policies, tools, and processes required to deliver software reliably at scale.

The distinction becomes more apparent as engineering organizations grow. Individual DevOps pipeline tools can address specific stages of software delivery, but coordinating workflows, enforcing governance, and maintaining visibility across multiple teams becomes increasingly difficult when every capability operates in isolation.

Siloed Tools vs Unified DevOps Platform. What's the Real Difference?

Standalone DevOps tools are designed to solve specific challenges, whether it is source code management, CI/CD, security testing, or infrastructure automation. As engineering organizations grow, however, connecting these tools through custom integrations, scripts, and manual processes can increase operational complexity. A unified DevOps platform brings these capabilities together into a single software delivery system, creating consistent workflows, centralized governance, and shared visibility across teams.

Fragmented toolchains introduce accidental complexity. As engineering organizations scale, teams spend increasing amounts of time maintaining integrations, troubleshooting workflow failures, and synchronizing data across multiple systems instead of improving software delivery. Over time, this creates integration debt, increases operational overhead, and makes it harder to standardize software delivery across the organization.

What are the hidden costs of siloed DevOps tools?

Specialized DevOps tools solve specific problems well, but they are not designed to operate as a single software delivery system. As organizations adopt more tools, engineering teams must maintain integrations, synchronize data, enforce consistent policies, and switch between multiple interfaces to complete everyday tasks.

Over time, this creates integration debt and operational complexity. Instead of improving delivery processes, platform teams spend valuable engineering effort maintaining the toolchain itself. The result is slower releases, inconsistent governance, limited visibility, and a developer experience that becomes increasingly difficult to scale.

What does a unified platform change?

A unified DevOps platform shifts engineering effort from maintaining tools to improving software delivery. Instead of coordinating work across disconnected systems, teams operate from a common delivery framework with standardized workflows, consistent governance, and shared operational context.

The benefits extend beyond operational efficiency. For example, Ancestry reduced pipeline maintenance by 85%, increased deployment frequency 3x, and cut downtime by 50% after standardizing software delivery with a unified platform. Rather than adapting processes to fit individual tools, engineering teams can scale consistent delivery practices across applications, services, and environments, freeing up time to deliver more value to customers.

‍Key capabilities of a modern DevOps platform

A modern DevOps platform should do more than automate software delivery. It should provide the capabilities needed to build, secure, deploy, and govern applications consistently across teams, environments, and cloud providers.

• Automated software delivery: Support CI/CD pipelines, deployment automation, rollback strategies, and release orchestration.
• Integrated security: Embed security scanning and policy enforcement throughout the software delivery lifecycle instead of treating security as a separate process.
• Artifact management: Securely store, version, and manage build artifacts and container images from a central repository.
• Enterprise governance: Enforce role-based access control (RBAC), audit trails, compliance policies, and approval workflows.
• Multi-cloud operations: Deliver applications consistently across public cloud, private cloud, Kubernetes, and on-premises environments.
• AI-powered assistance: Accelerate software delivery with intelligent recommendations, pipeline optimization, and automated troubleshooting.
• Operational visibility: Track delivery performance, cloud costs, and engineering metrics from a unified view.

As engineering organizations grow, the challenge is no longer adopting individual DevOps capabilities. It is operating them efficiently at scale. That is driving a broader shift toward unified platforms that reduce operational complexity while improving governance, visibility, and software delivery performance.

Why enterprises are moving to a unified enterprise DevOps platform

As engineering organizations grow, software delivery often becomes more difficult to manage than software development itself. New tools improve individual stages of the delivery lifecycle, but they also introduce additional licensing costs, longer onboarding cycles, fragmented visibility, inconsistent governance, and a broader security surface to manage.

This growing complexity is reflected in industry research. Forrester's The Forrester Wave™: DevOps Platforms, Q2 2025 reflects the industry's shift from evaluating individual delivery tools to assessing integrated DevOps platforms that support end-to-end software delivery.

Performance research reinforces the shift. Elite engineering teams deploy 182x more frequently than low performers (DORA, State of AI-assisted Software Development 2025), and that gap tracks closely with whether delivery runs on a unified platform or a fragmented toolchain. Together, these trends explain why enterprises are increasingly consolidating their DevOps toolchains into unified platforms, but which one should you go for?

How do you evaluate the best DevOps platform for your team?

Choosing a DevOps platform is a strategic engineering decision, not just a software purchase. The platform you select will influence how your teams build, secure, deploy, and govern software for years to come. Rather than comparing feature checklists, evaluate how well each platform supports your delivery workflows, integrates with your existing ecosystem, and scales with your engineering organization. In practice, the best DevOps platform is rarely the one with the most features. It is the one that fits the way your teams deliver software.

What should you look for when evaluating a DevOps platform?

When evaluating DevOps platforms, look beyond individual capabilities. Consider whether the platform can:

• Support your end-to-end software delivery workflows, not just CI/CD.
• Integrate with your existing developer tools, cloud platforms, and infrastructure.
• Enforce security, governance, and compliance without slowing software delivery.
• Scale across multiple teams, applications, and environments.
• Provide visibility into software delivery performance, reliability, and operational costs.

What questions should you ask before you commit?

Before making a decision, involve engineering, security, platform, and operations teams in the evaluation process. The answers to these questions will often reveal whether a platform fits your organization better than a feature comparison alone.

• Will this platform simplify our software delivery process or add another layer of complexity?
• Can it replace multiple point solutions without disrupting existing workflows?
• How much customization and ongoing maintenance will it require?
• Will it scale with our engineering organization over the next three to five years?
• Does it improve the developer experience while meeting enterprise governance requirements?
  

How Harness Delivers a Unified DevOps Platform | 120–150 words

Modern software delivery requires more than CI/CD automation. Teams need a platform that unifies software delivery, security, governance, cost management, and engineering insights without increasing operational complexity. Harness delivers this through an AI-native DevOps platform that brings together:

• Continuous Integration (CI)
• Continuous Delivery (CD),
• GitOps,
• Software Supply Chain Security (SSCS),
• Cloud Cost Management,
• Infrastructure as Code Management (IaCM), and
• Engineering Insights in a single platform.

Beyond consolidating capabilities, Harness helps engineering teams work more efficiently. AI-powered pipeline generation and optimization reduce manual effort, built-in governance enforces organizational policies across delivery workflows, and unified dashboards provide real-time visibility into deployments, reliability, compliance, and engineering performance. The result is a software delivery platform designed to help organizations build, secure, and deploy software with greater speed and consistency that engineering teams trust.

Choose unified delivery before fragmentation chooses for you

Every additional point tool starts as a fix for one problem and ends as one more system someone has to maintain, secure, and explain to a new hire. The question is not whether your DevOps tool stack will need to consolidate eventually. It is whether you do it on your own timeline or after the integration debt has already slowed delivery.

Start by mapping your own delivery workflow against the criteria above: integration, governance, scalability, AI capability, and total cost. 

See how Harness brings CI, CD, security, cost management, and engineering insights onto one AI-native platform.

What is a DevOps tools list (and what should it include)?

A DevOps tools list is the set of tool categories spanning the software delivery lifecycle, source, build, test, secure, deploy, and operate, that a team assembles into a working stack. A complete list covers every stage from code to production; a good one covers them with as few disconnected tools as possible. In 2026, the useful question is not how long the list is, but how few seams sit between the tools on it.

A new engineer joins a team and asks for the DevOps tools list. What comes back is a 22-line inventory: a source host, two CI systems, an IaC engine, a registry, three scanners, a deployment tool, a couple of dashboards, and nobody who can fully explain how they all connect. That inventory is the team's DevOps tools list, and its length is often mistaken for its strength.

A DevOps tools list is the connected set of tools spanning the software delivery lifecycle (source control, build, test, security, deployment, and operations) that a team assembles to move software from code to production safely and reliably. A useful DevOps tools list covers every stage with as few disconnected tools as possible. The goal is not the longest list. It is the smallest unified stack that lets teams ship faster and safer.

What is a DevOps tools list and what are the best DevOps tools and devops pipeline tools?

A functional DevOps tools list covers nine stages. Each stage has multiple options, but the principle is the same: choose devops pipeline tools that integrate well, then consolidate the integration points.

The categories matter less than the integration. CI that shares a policy layer with your CD platform and security testing is more valuable than three best devops tools with no shared context. The Internal Developer Portal is what surfaces these as golden paths developers self-serve on, rather than ticket queues they wait on.

What changed about the DevOps tool stack in 2026?

The categories above are not new. What changed in 2026 is the cost of how they are connected. AI moved into code creation, so more change flows through every stage—and the seams between separately chosen tools, each with its own access model and audit trail, became the place where governance and context break down. The list got longer; the gaps between its items got more expensive.

A useful DevOps tools comparison isn’t product-versus-product, it’s two ways of assembling the stack. The table below frames that DevOps tools comparison directly: the longer list against the right stack.

Why the longest DevOps tools list slows teams down

It is tempting to read a long tools list as a mature one. But each tool added to the list is another integration to maintain, another audit trail to reconcile, and another point where a security or quality check can be skipped. As AI raises the volume of change moving through the stack, those seams are exactly where speed turns into risk—the pattern Harness calls the AI Velocity Paradox.

Key data: Harness research (State of AI in Software Engineering 2025) shows 71% of teams say context-switching between tools drains productivity, and 73% of engineering leaders report barely any teams have standardized golden paths.

So the honest answer to "what's the best DevOps tools list" is not a longer list. It is a list short enough to govern consistently and complete enough to cover every stage—which usually means consolidating, not collecting.

What does the only DevOps CI CD tools stack you need in 2026 look like?

The answer is not a specific list of vendor names. It is a set of principles that any good DevOps tools list should satisfy.

• One policy engine across all stages. Governance should not vary by tool. A deploy gate in CD should enforce the same rules as a security gate in CI.
• One audit trail. Every change, approval, and rollback should be traceable in one place, not reconstructed from five different log systems.
• One data model. Delivery insights should span the full lifecycle so you can answer questions like why did deployment frequency drop this sprint without crossing four dashboards.
• Self-service with guardrails. Platform teams define the golden paths; developers execute them without filing tickets. This is what the Internal Developer Portal exists to provide.
• AI that acts on the pipeline. Not an AI sidebar you paste answers from but a system that selects tests, diagnoses failures, generates pipelines, and remediates incidents within governed guardrails.

Key Distinction: The only stack you need is not the longest tools list—it's the smallest set of governed categories that covers the lifecycle without sprawl. A consolidated stack that shares governance beats a longer one whose tools don't.

How Harness approaches the DevOps stack

The challenge

Platform teams are asked to give developers fast, self-service delivery while maintaining governance and reliability. As AI accelerates code output and tools accumulate, the after-code stages (testing, securing, deploying, operating) fragment across products with no shared context or governance. The platform team ends up maintaining integration seams instead of improving delivery.

The approach

Harness is the AI-native Software Delivery Platform that automates and governs everything after code is written. The Software Delivery Knowledge Graph ties each build, deployment, and security event back to the service and commit it came from. On that foundation sit the after-code modules: Continuous Integration, Continuous Delivery and GitOps, the Internal Developer Portal, Infrastructure as Code Management, Application Security Testing, AI SRE, AI Test Automation, and Cloud and AI Cost Management. Each inherits shared access control, governance, and a single audit trail. Developer-friendly guardrails.

The outcome

Consolidating the stack onto one governed platform helps reduce the governance gaps and integration toil that sprawl creates, accelerates remediation when something breaks, and lets teams ship faster and safer as AI raises the volume of change. The aim is not the longest tools list, but the smallest one a team can govern with confidence.

 See how teams have simplified their stacks.

What does a consolidated DevOps stack look like in practice?

Two teams, two different sprawl problems, one outcome: consolidation returns engineering time to the work that actually needs it.

How did OneAdvanced enable 700 engineers with one governed DevOps tools list?

OneAdvanced managed over 100 product teams and 700-plus engineers deploying across six data centers, each with a different combination of Jenkins, CloudFormation, Octopus Deploy, Puppet, and Bash scripts. Pipelines took 3 to 30 hours to execute. Consolidating onto Harness CD gave every team self-service deployment on one governed platform. Average deployment time fell 88% from 2 days to 2 hours.

“We've conservatively saved 50 to 60% of total DevOps and engineering time spent on deployments and our previous CI/CD process.”

Martin Reynolds, DevOps Manager, OneAdvanced

Source: OneAdvanced enables 700 engineers with Harness

How did Deluxe standardize CI/CD pipelines across a fragmented devops tool stack?

Deluxe, a payments and data leader, had grown a wide technology footprint. Teams relied on custom scripts, multiple tools, and no centralized governance. Adopting Harness gave Deluxe standardized CI/CD templates and centralized governance across teams. Pipeline setup time dropped from days to under 30 minutes using reusable templates.

“With Harness CD, one of the biggest improvements is the confidence we have in deployment. Gates ensure only the right things are deployed, and rollback scripts are already embedded.”

Pankaj Gupta, Executive Director of Enterprise Architecture, Deluxe

Source: Deluxe reduces CI/CD pipeline setup time with Harness‍

Build the DevOps tools list that scales, not the longest one

The best DevOps tools list is not the most comprehensive. It is the one where fewer, well-integrated devops pipeline tools replace fragmented point solutions, and where adding the hundredth team costs about what adding the tenth did. Start from the governance gaps: find the stages where your audit trails break, where approvals depend on a human remembering a step, where a deploy needs someone to watch a dashboard. Those are the integration seams worth removing.

A unified platform covering the after-code lifecycle with shared governance, golden paths, and AI-native automation is how teams absorb AI-generated code at machine speed without losing control of what ships. 

See how Harness brings the full after-code lifecycle onto one platform.

In the fast-paced world of modern software delivery, compliance is often a bottleneck. While our existing OPA-based Policy as Code feature has long empowered teams to encode complex authorization checks and enforce granular governance across their DevOps workflows, we know that starting from a blank page can be daunting. Security and governance teams struggle to keep up with the volume of releases, while developers often find the initial setup of these policies to be time-consuming.

Today, we are thrilled to announce a significant leap forward in automated governance: Policy Packs.

What Are Policy Packs?

Policy Packs are a curated library of pre-written Rego policies designed to align your software delivery lifecycle (SDLC) with the most popular compliance frameworks.

By providing out-of-the-box policies, we are eliminating the primary barrier to automated governance: the need to write and maintain complex Rego code from scratch. With Policy Packs, you can adopt industry-standard guardrails by adapting our out of the box policies from the policy packs with zero to little customization. This will allow your teams to focus on shipping features rather than writing policy.

Comprehensive Framework Coverage

Our Policy Packs initiative covers the frameworks that matter most to your business and your auditors:

• SOC 2: Focuses on trust service criteria like security, availability, and processing integrity. Our policies help enforce peer-reviewed pull requests and automated change management gates.
• NIST: Specifically targeting SP 800-53 and 800-171, these policies cover configuration management, system integrity, and supply chain risk management via automated SBOM generation and SLSA provenance.
• PCI DSS: Designed for organizations handling payment card data, these policies enforce secrets management, network segmentation, and mandatory vulnerability patching.
• HIPAA & HITRUST: For those dealing with protected health information (PHI), these packs provide automated data leakage prevention and secure API monitoring.

Turning Framework Requirements into DevOps Controls

Compliance is no longer just a "point-in-time" audit; it’s a continuous process. Policy Packs map technical events directly to framework controls, providing the evidence your GRC teams and auditors need.

Common Compliance Challenges in DevOps

In our work with industry leaders, like those in highly regulated industries such as healthcare, finance, or insurance, we’ve seen that compliance is often a manual, high-friction process that slows down software delivery. Two of the most common challenges teams face are:

• The "audit readiness" blind spot: Teams often struggle to prove that their pipelines are consistently secure. Without automated guardrails, compliance is only checked during point-in-time audits, leaving gaps that are hard to identify and remediate.
• The manual approval bottleneck: Many organizations rely on manual checkpoints to satisfy framework requirements. This frustrates developers who want to move fast, leading to "compliance fatigue" where processes are bypassed or ignored.

Harness Policy Packs address these challenges by shifting governance left, embedding compliance checks directly into your CI/CD pipelines so that validation happens automatically with every commit.

Example Policy: Enforcing Separation of Duties

A classic requirement for frameworks like SOC 2 and NIST is "Separation of Duties." In a modern DevOps workflow, this means the person who writes and commits the code cannot be the same person who approves the deployment to production.

To enforce this, a compliance policy in your pipeline would verify the identity of the commit author against the identity of the deployment approver. If the system detects that the author and the approver are the same individual, the policy automatically blocks the deployment. This ensures that every production change has been independently peer-reviewed, providing auditors with a tamper-proof guarantee that your internal controls are working as intended without requiring manual intervention from your GRC team.

Why This Matters

1. Shift governance left: Catch violations before they ever reach production by enforcing policies during the save, run, or step phases of your pipeline.
2. Accelerate audit readiness: Move from "preventing risk" to "proving compliance" with a tamper-proof evidence vault that stores all builds, scans, and approvals.
3. Reduce risk: Mitigate legal and audit risks by using policies that are directly mapped to specific framework controls.
4. Universal coverage: Whether you are using CI, CD, Feature Management, or Cloud & AI Cost Management, our one framework provides cross-module coverage across the entire platform.

Get Started Today

The journey to automated compliance doesn't have to start with a blank page. Get access to our policy packs in the repository here to get started. You can leverage our native Git integration for OPA rego policies to fork the policies from the repository linked above and import them into your account.  

Get ready to stop audit delays before they start. 

Harness has been recognized as a Leader in the 2026 Gartner® Magic Quadrant™ for DevSecOps Platforms for the third consecutive year. Harness was also positioned furthest on the Completeness of Vision axis in the report.

Our Key takeaways:

• Harness is named a Leader for the third consecutive year
• Harness is positioned furthest on the Completeness of Vision axis
• Harness continues investing in governed, AI-powered DevSecOps

Harness is the AI platform for engineering, security, and operations teams to build, secure, deploy, govern, and optimize software delivery across the SDLC.

We believe our recognition  in the Gartner Magic Quadrant for DevSecOps Platforms reflects the continued evolution of the Harness platform and our commitment to helping teams deliver software faster, safer, and with greater governance across the software delivery lifecycle.

We’re thrilled to share this recognition, which we believe reflects the strength of our product strategy, the breadth of our platform, and our continued investment in helping enterprises modernize software delivery with security, reliability, cost management, and AI built into the development lifecycle.

Today, organizations across industries like United Airlines, Ancestry, and Citi rely on Harness to reduce delivery complexity, improve developer productivity, strengthen governance, and accelerate innovation across increasingly complex software environments.

Why This Matters Now

Software delivery has entered a new era. AI coding assistants are helping teams create software faster than ever, but faster code generation also means more changes, more tests, more vulnerabilities, more deployments, and more incidents for organizations to manage. The next era of DevSecOps will not be defined by who can generate code faster. It will be defined by who can safely convert that speed into reliable business outcomes.

Our view is that the future of DevSecOps is autonomous AI agents, governed and directed by expert engineers. As humans and AI agents both contribute to software change, enterprises will need one connected platform to understand, validate, secure, deploy, observe, optimize, roll back, and prove every change across the software delivery lifecycle.

Our Journey

As a pioneer in modern software delivery, Harness offers over 15 platform products and has built one of the industry’s most comprehensive platforms to support the full spectrum of application development, deployment, security, reliability, feature management, cost management, and operations.

Harness has evolved through a combination of product innovation, internal entrepreneurship, open source investment, and strategic acquisitions. We believe our recognition as furthest on the Completeness of Vision axis in the 2026 Gartner® Magic Quadrant™ for DevSecOps Platforms is proof that Harness is solving problems for our customers in a measurable way.

Over the past year, Harness has continued to expand platform capabilities and AI agents across: 

• Security and risk management
• AI-native testing capabilities including flaky test detection and AI impact testing
• Feature Management and Experimentation
• Cloud and AI Cost Management
• AI DLC insights
• Resilience Testing, and more

This matters because software delivery is no longer just about building and deploying code. Teams must now manage security risk, release complexity, infrastructure cost, compliance requirements, production reliability, and the growing impact of AI-generated software. The Harness platform allows teams to adopt what they need, when they need it, in one place.

With operations across North America, Europe, APAC, Latin America, and India, Harness serves organizations of all sizes across industries. Customers choose Harness not only for the breadth of the platform but also for the flexibility to adopt individual modules or the full platform based on their needs, maturity, and business priorities.

What’s Next for Harness

This recognition in our opinion is a milestone, and we’re proud, but we’re even more excited by the road ahead.

We build security in the software delivery lifecycle natively, not as a separate stage or disconnected toolchain. As AI increases the volume of code, changes, and security findings, enterprises will need platforms that connect detection, prioritization, policy, remediation, deployment, and runtime defense into a single, governed workflow.

Harness is focused on helping enterprises meet that moment. We will continue investing in AI software delivery to help teams move faster without losing control. Our goal is to help every organization deliver software that is faster to build, safer to release, easier to govern, and more resilient in production.

Thank you to our customers, partners, employees, and community for your continued trust. We’re excited about the journey ahead and can’t wait to show you what’s next.

Learn More

Get a complimentary copy of the 2026 Gartner® Magic Quadrant™ for DevSecOps Platforms.

Or, to talk to someone about Harness, please contact us.

Gartner Disclaimer

Gartner, Magic Quadrant for DevSecOps Platforms, 2026, Keith Mann, Thomas Murphy, Bill Holz, 15 June 2026 

Gartner does not endorse any vendor, product, or service depicted in its research publications and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

GARTNER is a registered trademark and service mark of Gartner, and Magic Quadrant is a registered trademark of Gartner, Inc. and/or its affiliates in the U.S. and internationally, and is used herein with permission. All rights reserved.