Pipelines and releases
How a change moves from commit to a release, with gates and visibility along the way.
Delivery on IntegraCI is one model that works the same way across targets. You keep the CI engine you run; the platform orchestrates the pipeline around it, gates it with policy, and gives you one place to watch and control a release.
The pipeline
A pipeline is the sequence a change moves through: build, test, scan, and the gates that decide whether it proceeds. IntegraCI sees the pipeline state whatever CI you use, and renders it as one view rather than a log you have to decode. Your build runners still build and your scanners still scan; the platform sequences and gates the steps.
Pipeline studio
For teams that want to shape the pipeline visually, pipeline studio lets you compose stages and gates without hand-writing every detail. The output is still version-controlled, so the pipeline is reviewable like any other change.
Gates decide what ships
Between stages sit gates: policy as code that reads the results so far and decides pass or stop. A change that fails a gate stops there, loudly, with the reason recorded. See Security gates for how the security checks feed this.
Releases and environments
A release moves a built, gated artifact toward your environments and targets. Because desired state is version-controlled and reconciles through GitOps, any release is reviewable before and reversible after. Feature flags let you ship a version and turn it on separately.
Next
For the deploy mechanics, including progressive delivery, drift detection, and rollback, see Deploy a service.