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.
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. If you pick it as a target on its own, Mochi says so and asks you to choose the pipeline instead. That way a change can't land in QA or production having skipped the stages, and the checkpoints, ahead of it. An environment that isn't on a pipeline at all can still be updated directly, since there's nothing to skip.
Automatic or manual
A pipeline can start on its own when a change is ready, or wait until you start it. Each stage can move along on its own too, or wait for your go-ahead, so you keep hands-on control exactly where you want it.
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.
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 run the pipeline 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 run delivers a change there, once any checkpoint you set has been cleared. It only makes the changes you've set up.