Skip to main content
Ravion Pipelines are a full-featured CI/CD system that runs in your cloud account. They are optional for you instead of using GitHub Actions or CircleCI. Regardless, you will need to have a pipeline somewhere to build your code, upload the artifacts to a store, and trigger a deployment of that in Ravion.

​
Two kinds of pipeline runs

Pipelines fill two roles in Ravion, and you’ll see both in your run history:
  1. Pipelines you author — build and deploy workflows triggered by git pushes, the API, or manually. These are the optional replacement for GitHub Actions described on this page.
  2. Stack pipelines — the change and destroy pipelines attached to every module stack, which run Terraform plan → approval → apply whenever a module’s infrastructure config changes or the module is deleted. By default these are Ravion-managed system pipelines; your platform team can substitute custom ones.
When other docs mention a “stack change pipeline run”, it’s the second kind: a normal pipeline run that was triggered by a config change instead of a git push.

​
One pipeline, many environments

A pipeline describes a workflow, not an environment. Don’t create a “Production pipeline” and a “Staging pipeline” — create one pipeline named after what it does, like Build & Deploy, and add a variant per environment. Steps reference module instances through << pipeline.variant.id >>, so the same steps deploy to whichever environment a run targets:

​
One workflow per pipeline

A pipeline should contain steps that depend on each other. If two sets of steps never consume each other’s outputs and never need to wait on each other, they are separate workflows — make them separate pipelines, not parallel groups in one pipeline. The common mistake is a pipeline shaped like this:
Nothing in the API branch reads from the Marketing site branch. Packing them together only couples them: a failing site build marks the whole run failed, every trigger runs both even when only one changed, and you can’t re-run one without re-running the other. Split them into an API pipeline and a Marketing site pipeline, each with its own trigger and its own build → deploy steps. Keep steps in the same pipeline when they share a dependency:
  • A deploy that pins the image digest from a build.
  • One image build that several module instances deploy.
  • A test or terraform:plan step that gates a deploy or apply.
  • An approval that several deploys wait on.
  • Services that must roll out together, in a fixed order, because of a schema or API contract.
Use parallel for steps that can overlap inside one of these workflows — build two images before a shared deploy stage, or fan a single build out to several deploys. Reach for group only occasionally: it labels a nested sequence in the UI and can carry a concurrency key for the block as a whole, so it’s useful to hold a multi-step branch inside a parallel block. A pipeline whose top level is nothing but parallel groups is almost always several pipelines. See Blocks for the semantics.

​
You might want to use Ravion pipelines for the following reasons:

1
You get a single pane of glass and CLI/API surface area to see all your builds, deploys, and infrastructure.
2
You get enhanced security and control because you no longer have to open up your database or image registries to GitHub Actions. Ravion pipelines execute entirely in your cloud account.
3
You can define all your build configuration in the module alongside your runtime config.
See Pipeline configuration for the detailed config schema.