Core concepts

Undoing changes

Two ways to undo a configuration change: roll an environment back to an earlier version right now, or revert a change so it's no longer part of your configuration at all.

Mochi Deploy manages your Aprimo configuration: fields, content types, classifications, rules, and settings. Sometimes a change needs undoing: something reached an environment and caused a problem, or a change that's part of your configuration shouldn't be. Mochi gives you two tools for that, and they do different jobs.

Roll back an environment

Rolling back puts the configuration Mochi manages in one environment back to an earlier version. That includes anything changed in the environment directly since, which is usually the reason for rolling back in the first place. Items you don't track are left exactly as they are. It's the quick fix for “something reached this environment and I need it the way it was.” It changes only the items you track. Anything else in that Aprimo instance is left alone. Every environment keeps a version history (the versions it has been brought to), and you pick the one to return to.

Open the environment from the Environments tab.
Open Version history. Each entry is a version this environment has held, newest first, with the current one marked.
Choose an earlier version and select Roll back. Before anything happens, Mochi reads the environment as it is now and shows what the rollback would do: which items get deleted, which get put back (including anything deleted directly in Aprimo since), and which return to earlier settings. Confirm, and Mochi restores the live configuration in that environment to how it was at that version.

How a rollback is gated, and what it doesn't do

Whether a rollback needs approval is set per environment (in Settings, under the environment's menu). By default it happens right away, for putting things right quickly; an environment can instead wait for someone to approve the rollback first, which is useful where Mochi is the only sanctioned way to change that environment. Rolling back a production environment that doesn't wait for approval asks you to type its name first; either way, every rollback is recorded. It runs the same safety checks a delivery does, meaning Mochi's own gates; the checks you write belong to pipeline stages and don't run on a rollback, so run them yourself afterwards if you want to know how the environment looks now. And it isn't a full restore: it moves only the items you track and keeps no snapshot, working out the earlier version from your change history. The changes you rolled back are still part of your configuration, so they can reach the environment again later; to make the undo permanent, revert those changes too.

Revert a change

Reverting undoes a change in your configuration itself. It creates a new change set that reverses an earlier one, and that new change set moves through your pipeline to your environments like any other change. Use it when a change shouldn't be part of your configuration anymore.

An undo can delete. If the change set being reverted added items, the undo removes those items from every environment it's delivered to. The undo's page says so before anyone approves it: This undo deletes N items, followed by the list, so nobody has to work it out from the description. It removes them as they are now, later edits included, and undoing that undo puts them back the same way: an undo works on your configuration as it stands today, not as the original change left it.

An undo of a rename renames the item back. Nothing is deleted and nothing is added: the item gets its earlier name again, in your configuration and in every environment the undo reaches, and anything that points at it keeps working. A rollback across a rename does the same in that one environment, and the preview lists the items it renames back.

Open the change in Change sets. A change can be reverted once it's part of your configuration.
Select Revert. Mochi creates a new change set that reverses it. The button on the original says Revert; the change set it creates is labelled Undo, with a note of what it reverses. Same thing, seen from either end.
It gets approved like any change. If your workspace asks for approval, the undo waits for it too, and the approvers hear about it. With approvals off it's part of your configuration straight away.
It travels like any change. The reversal reaches your environments the same way the original did: along a pipeline when someone starts a run, and on an environment that is on no pipeline through Update on that environment's page, which appears while it is behind. Nothing is sent on its own.

Once per change

A change can be undone once. If someone got there first, Mochi tells you so instead of making a second reversal, and says whether the undo has already gone through or is still waiting to be approved. If an undo was turned down, the change can be undone again later.

When an undo no longer fits

An undo has to fit what your configuration holds now. If a later change set has already changed the same items, Mochi won't undo just the earlier one, because that would quietly take the later change back too. Undo the later change first. And if an item the change set removed has since been tracked again, or an item it added is no longer tracked, there's nothing to undo and Mochi says so. Either way, your configuration isn't touched until the whole undo fits.

Which one to use

Roll back when you need an environment fixed now. Revert when a change should leave your configuration for good. Often you'll do both: roll an environment back to stop the problem immediately, then revert the change so it doesn't come back the next time that environment is brought up to date.

PreviousChecks NextBroken references