Pipelines
A pipeline is an ordered path that carries a configuration change from one environment toward a production environment, with an optional checkpoint for an approval along the way.
Once a change set is part of your configuration, it still doesn't reach your other Aprimo instances until you send it there. A pipeline is how it travels. You lay out the environments it passes through, in the order you want, ending at a production environment.
Turning pipelines off again hides every pipeline and its stages, and an update sent straight to an environment then follows none of their rules: nobody has to approve it, no checks run, and a change made directly in the environment stops it (the stage's choice to restore the approved version instead doesn't apply). Turning one pipeline off is different. Its stages and their rules stay in place, but nothing runs along it, automatically or when you start it, until it's on again.
Stages and order
Each environment on the path is a stage. Because environments have no fixed order of their own, the pipeline is where that order is decided: you might go from a sandbox, to QA, and finally to production. A workspace can have more than one pipeline when different parts of your setup need different paths.
A production stage is the end of the line: nothing comes after it. A pipeline can finish at more than one production environment, and when it does, those production environments are delivered at the same time.
Everything takes the path
An environment partway down a pipeline gets its updates from the stage in front of it, so a change reaches it by travelling the path. Choose New run on the pipeline, and the run enters the first stage that is behind and delivers along the path from there. A stage can only receive what the stage in front of it holds, which is what keeps a change from landing in QA or production having skipped the stages, and the checkpoints, ahead of it.
Automatic or manual
A pipeline can start on its own when a change is ready and carry it from stage to stage, or wait until you start it. On a pipeline you start yourself, each run lands on the stage you send it to and the next stage waits until you start a run for it, so nothing moves on without you.
An automatic pipeline never moves past a delivery that stopped at a safety check. The stage waits for a person, and change sets that arrive in the meantime wait behind it. The environment's line shows the blocked delivery and how many change sets are waiting on it. See When a delivery stops.
Checkpoints
At any stage you can add a checkpoint: a point where the change pauses and waits for approval before it's applied. Put one wherever a change deserves a second look, most often just before a production stage. A stage with no checkpoint simply carries the change through.
Checks at each stage
Each stage also decides what to do with your checks. Under Checks, a stage can run them and record the results (how a new stage starts out), run them and stop the delivery if any fail, or not run them. A stage can run only the checks carrying a particular tag, so a sandbox might run a quick set and production the whole set.
Checks that read the configuration are tested before anything is written, against what the update would produce. On a stage set to stop, a failure there stops the run before it changes anything. Once the update has landed, every selected check runs against the environment as it now is. A failure at that point, on a stage set to stop, marks the run failed and the next stage doesn't start; the update itself stays. The run's page shows both under Checks, below Mochi's own safety checks. See Write a check for the steps.
When an environment was changed directly
Sometimes a tracked item gets changed straight in an environment, outside of a pipeline. Each stage decides what a run does when it arrives and finds one of those changes waiting there.
- Stop and send a notification. The run stops before it changes anything and sends a notification. Someone can undo the change in the environment, or capture it into a change set so it becomes part of the tracked configuration, and then update the environment again. This is the default, so a change made directly isn't replaced unless someone decides to.
- Restore the approved version. The run replaces the changed item with the approved version and carries on, so the stage always matches what was approved. Choose this for a stage you want to keep exactly in step with the approved configuration, with no stops.
Either way, this only ever touches the configuration items you track. Anything in the instance that isn't tracked is left alone.
Mochi changes an environment when a delivery reaches it, once any checkpoint you set has been cleared. It only makes the changes you've set up.