Pipelines as code

Everything you build in the BARRY UI can also be described as code. Pipelines-as-code adds a name-based YAML layer over the runtime's existing model, so the same transports, connections and triggers you click together can be versioned, reviewed and promoted like any other software.

Each object — a connection, a transport, a trigger, an alert, an output format — has a YAML representation keyed by a stable name rather than an internal id. You can edit it in the UI's built-in editor, with a proper diff view, or in your own tooling. The layer is deliberately additive: it sits on top of the unchanged identity model, so adopting it never rewrites what you already have.

BARRY connects to a Git repository, with one repository and a branch per environment. Changes are committed from the UI or pushed from outside, and before anything is applied BARRY shows you the difference between what is running in the environment and what is in the branch, as a side-by-side diff and a dependency graph.

Promotion is selective. You pull specific objects upstream — from dev into staging, say — review exactly what would change, and apply only what you meant to. Because objects are keyed by name, a transport keeps its identity as it moves between environments even though the underlying ids differ, so the same pipeline in dev and in production is recognisably the same pipeline.

The result is the workflow teams already trust for application code — write it down, review it, promote it — applied to data pipelines, without giving up the convenience of the UI for everything else. You can live entirely in YAML, entirely in the UI, or move between them; the two are views onto the same objects.

← All documentation