Run a pipeline

A pipeline is an ordered path of environments that ends at a production environment. A run delivers a change set along that path, one stage after another.

Start a run

1. Open the pipeline from Pipelines. Each stage shows one line saying where it stands, such as Now at #115 · latest #118 · 3 behind. The number is the change set, and “behind” counts change sets.
2. Choose New run.
3. Pick the change set under Bring up to. The newest is picked for you.
4. Choose Run. The run enters the first stage that is behind. On a pipeline set to run automatically it moves on toward production from there, pausing at any gate; on a pipeline you start yourself, it stops at that stage and the next one waits until you start a run for it. It appears in Runs.

Passing the gates

A pipeline can move a change on to the next stage automatically or wait for you to start it, and a stage can ask for approval before a change lands there. When a delivery reaches a stage that needs approving, it pauses until enough approvers say yes, then carries on. The environment's line shows what it's waiting on, and Runs shows the whole delivery.

Turning down a delivery turns down that delivery. The change sets stay in your configuration and are part of the next delivery, which asks again. If you never want a change set, undo it.

What can stop a run

Before a run changes anything in an environment, Mochi runs a few safety checks over what it's about to deliver. If one doesn't pass, the run stops at that stage without changing anything, and tells you what it found so you can put it right and run again. A run stops when:

• The change wouldn't be valid. Something about it doesn't hold together on its own.
• It would leave something pointing at configuration that isn't there. If an item you're delivering depends on another item, that item has to be in the target environment It can already be there, or be brought along by this same run. If the target environment already has it, that's fine, even if you don't track it. The run only stops when the dependency truly isn't there, because delivering the item would leave it pointing at nothing.
• The target was changed directly in Aprimo. If a tracked item was edited in the environment outside Mochi since the last delivery, the run stops rather than overwrite that change. A stage can be set to restore the approved version instead, in which case the delivery goes ahead and brings the item back in line.
• One of your checks would fail. On a stage set to stop when a check fails, the checks that read the configuration are tested against what the update would produce, and a failure stops the run before anything is written. The run's page lists them under Checks, below the safety checks.

Checks also run once the update has landed, against the environment as it now is. Those can't stop the update, because it has already happened. On a stage set to stop, a failure there marks the run failed and the next stage doesn't start; the update stays in place until someone decides what to do about it.