A run doesn’t go straight from work to production. It travels a path you design: the project’s pipeline.
Pipeline
Every project has one pipeline — the ordered route a delivery follows. You design it on the project’s Pipeline page, laid out left to right as a row of stages connected by arrows.
You can start from a template or build the pipeline by hand:
- Simple — two stages, development and production. A good default.
- Standard — three stages: development, staging, production.
- Enterprise — four stages: development, QA, UAT, production.
- Custom — an empty pipeline you fill in yourself.
A template is only a starting point. Once it’s loaded you rename stages, add or remove them, reorder them, and change their settings. A pipeline can hold up to 20 stages.
Stage
A stage is one step on that path. Each stage has two things that matter:
- A name — what you call this step (for example, Development or Production).
- A branch — the branch in your repository this stage targets.
When a run reaches a stage, DIJJI.ai opens a pull request against that stage’s branch. That pull request is the delivery for that stage — the change, ready for you to look at. The run then waits at the stage’s gate.
Stages run in order. The run finishes the first stage, then moves to the second, and so on to the last.
Gate
A gate is the checkpoint at the end of a stage: what must be true before the run may move on? For every stage the baseline is the same — the stage’s pull request must be merged before the run advances. What you control is who merges it, and whether anything else has to be true first. There’s no single “gate type” menu; instead, three stage settings shape the gate:
- Auto-merge PR — the main control. Left off (the default), the run waits for you to merge the stage’s pull request: merging is your approval, and nothing advances until you do it. Turned on, DIJJI.ai merges the pull request itself and the run flows straight through with no pause. So off is a human checkpoint; on is hands-off. (Turning it on for a production stage skips human review — and the merge can fail if the branch has protection rules.)
- Wait for deploy confirmation — when on, holds the stage after its pull request is merged until the merged code is confirmed deployed, so the run doesn’t move ahead of the deployment. See Deploy confirmation and the deploy wait.
- E2E trigger — when a stage is set to run end-to-end tests, the stage also waits for those tests before it clears. See Trigger E2E tests manually.
The gate is what gives you control. Leaving Auto-merge PR off on every stage stops the run at each one and waits for you; turning it on lets stages flow through. Most pipelines mix the two — careful where it counts, quick where it doesn’t, commonly a human merge on every stage except a hands-off final one.
Where a stage ends
One more setting decides what happens once a stage clears its gate:
- End-of-stage behavior — advance to the next stage (the default), or stop, ending the pipeline here. Only the final stage should stop; an earlier stage set to stop would strand the stages after it.
How it fits together
Pipeline
└── Stage → opens a pull request on a branch
└── Gate → decides whether the run advances
A run moves through this pipeline one stage at a time. To see what a run is doing while it sits at a gate, and the work itself, start with Projects, tasks, and runs.