Pipelines: CI/CD with policy gates and provenance built in
Reusable pipeline templates, organisation policy applied at the gate rather than in review, and a provenance record that traces every running container back to the commit that produced it.
What is Pipelines?
DevOpsArk Pipelines is the continuous integration and delivery engine that runs build, test, scan and deploy stages against shared templates, enforces policy gates between stages, and records provenance for every artifact it produces.
What Pipelines is for
The conditions this module removes. If none of these are familiar, you probably do not need it yet.
- Every repository has a slightly different pipeline, so a change to the security stage means forty pull requests.
- Policy lives in code review. If a reviewer is busy, an unscanned artifact reaches production.
- Nobody can trace a running container back to a commit without opening three systems.
- Pipeline runtimes creep upward and no one owns the number.
- Secrets are pasted into pipeline variables and never rotated.
Pipelines are defined as versioned templates owned by the platform team and referenced (not copied) by each service. A service declares which template it uses and supplies only its own parameters, so a change to the shared template applies everywhere on the next run. Between stages sit policy gates: a build cannot enter the deploy stage unless the image scan passed, the tests met the coverage floor and the change carries the required approvals. Every stage writes to a provenance record that links commit, build inputs, image digest, scan verdict, approver and deployment target, so the question "what is actually running and where did it come from" has one answer. Secrets are read at runtime from the secrets module rather than stored as pipeline variables.
What Pipelines does
The 8 capabilities that make up Pipelines.
Shared pipeline templates
Templates are owned centrally and referenced by services, so a change to a stage rolls out estate-wide without touching each repository.
Policy gates between stages
Scan verdicts, coverage floors, approval requirements and change windows are enforced by the pipeline, not by whoever reviews the pull request.
Artifact provenance
Commit, build inputs, digest, scan result, approver and target environment are recorded as one chain for every artifact.
Parallel and conditional stages
Fan out tests across shards, skip stages that a change cannot affect, and fail fast on the stage most likely to catch the problem.
Runtime secret injection
Credentials are fetched from the secrets module at execution time and never persisted as pipeline variables.
Pipeline duration tracking
Stage-level timing history with a trend, so a slow creep is visible before it becomes a twenty-minute feedback loop.
Agent-assisted failure triage
Ark classifies a failure as flaky test, infrastructure fault or genuine regression by comparing it with recent runs of the same stage.
Preview environments
Open a pull request and get a disposable environment built from the same pipeline that will build production.
How Pipelines fits together
Outcomes
- A security or compliance change to the build process ships once, not once per repository.
- Unscanned or unapproved artifacts cannot reach production, because the gate is in the pipeline.
- Audit questions about a running workload are answered from the provenance chain in seconds.
- Flaky tests are separated from real regressions instead of being retried blindly.
- Pipeline secrets stop accumulating in CI settings pages.
Using Pipelines, step by step
The path from connecting a source to getting value, in the order it happens.
- 1Define the template
The platform team publishes a versioned pipeline template with its stages and policy gates.
- 2Reference it from a service
A service declares the template and supplies only its own parameters.
- 3Run on trigger
A push, pull request, tag or schedule starts the pipeline.
- 4Pass the gates
Scan verdicts, coverage and approvals are checked between stages before the run continues.
- 5Record provenance
Commit, digest, verdict, approver and target are written as one chain.
- 6Hand off to delivery
A passing artifact is released to ArkCD for reconciliation into the target environment.
Where teams apply Pipelines
Roll out a build-process change estate-wide
Update the shared template once and have every service pick it up on its next run.
Prove what reached production
Produce the commit-to-container chain, including the scan verdict and the approver, for any workload on request.
Get a preview environment per pull request
Review a change in a running environment built by the same pipeline that will build production.
Keep the feedback loop short
Watch stage duration trends and cut the stage that has quietly doubled over the last quarter.
What Pipelines works with
Named integrations link to their own page. The rest are supported runtimes and formats.
Pipelines: frequently asked questions
The 9 questions teams ask most often before adopting Pipelines.
A CI/CD pipeline is an automated sequence of stages that takes a code change from commit to running software, typically build, test, scan, package and deploy. Continuous integration covers the stages that verify the change; continuous delivery covers the stages that release it.
No. DevOpsArk Pipelines can run the whole lifecycle, or it can sit alongside an existing CI system and supply only the containerization, scanning, policy-gate and provenance stages. Many teams start with the second and migrate later.
A policy gate is a condition the pipeline enforces between stages, for example, that an image scan reported no unresolved critical findings, that test coverage met a floor, or that a change outside the deployment window carries a named approval. If the condition fails, the run stops.
Provenance is the recorded chain linking a running workload back to its origin: the commit, the build inputs, the image digest, the scan verdict, the approver and the environment it was deployed to. It is what lets you answer "where did this container come from" without reconstructing it.
Secrets are fetched at execution time from the DevOpsArk secrets module using a short-lived token scoped to that run. They are not stored as pipeline variables and do not persist after the run ends.
Yes. A pull request can trigger a disposable environment built by the same pipeline that builds production, so the review happens against running software. The environment is destroyed when the pull request closes.
Ark compares the failing stage against recent runs of the same stage on unrelated commits. A test that fails intermittently across unrelated changes is reported as flaky; one that starts failing at a specific commit is reported as a regression.
Yes. A single pipeline can target Kubernetes clusters and managed services across AWS, Azure and Google Cloud, with per-target policy gates and approvals.
Pipelines produce and verify the artifact; ArkCD reconciles environments against it. The handover is an image digest, so what was tested and scanned is exactly what is deployed.
See Pipelines against your own environment
A 30-minute walkthrough with a platform engineer, not a sales deck. Bring a cluster and a problem.