Pipelines

Plural Pipelines provide a way to automate the GitOps changes necessary to promote software across environments. The standard approach would be something like this:

1. Create a PR for dev, wait for review and merge
2. Create a PR for staging, same as above
3. Finally, create a PR for prod and you're done.

This is tedious and completely unnecessary. You'll also want to automate a variety of confirmation tests along the promotion process, which can be missed in a manual pattern.

Plural solves this by:

1. Allowing users to define their promotion flow via CRD
2. Auto-generating a PR at each stage using Plural's PR automation capabilities.
3. Using gates between stages to control promotion, with a variety of checks that can be performed.

Pipeline Flavors

There are two ways to accomplish a pipeline with Plural:

• Deterministic PR Automation-based pipelining
• AI-based PR pipelining

The main difference is that the second uses prompting plus lightweight coding agents to make the YAML changes needed to promote your software. Since these are usually small config changes, this approach is very reliable and often much easier to set up for developers of all skill levels, but for teams that want the security of determinism, that option is available as well.

Before we go into exact pipeline examples, assume we have two Plural services defined in a file bootstrap/guestbook.yaml like so: