Revert Process

While users create temporary kitchens as experimental sandboxes, your Automation tenant likely has kitchens designated as development and production environments. Merges into these environments are considered deployments and should be carefully controlled. For this reason, it is possible to revert a kitchen to a previous stable state.

By reverting a single update or merge, users have the opportunity to fix bad code and retest before attempting another merge. If several updates and merges have occurred, users can revert each one to determine where the problem lies.

A kitchen revert returns a kitchen to the immediate previous state, one state at a time, from most recent to oldest.

Revert with caution. Kitchen revert will roll back previous updates and merges and can impact your environment. The kitchen-revert command should only be used with caution!

Scenario 1: Develop and deploy

A user creates a child kitchen and commits two updates. Meanwhile, there is a change performed in the parent kitchen. The user merges the parent kitchen down (Merge1), as per best practices, so that the parent change is merged into the child kitchen. Then the user merges the child kitchen up (Merge2) into the parent. A subsequent change gets committed in the parent kitchen (Parent3).

Scenario 2: Revert

A data engineer discovers an issue in the parent branch and wants to revert changes until all recipe variations run correctly again. They are unsure where the problem was introduced.

First, the data engineer performs a kitchen-revert command on the parent kitchen to place that kitchen into the previous state, before the most recent update (Parent3).

Testing reveals that the problem still exists, so a second kitchen-revert is performed to roll back the child kitchen merge (Merge2).

The system rolls the merge back and leaves a no-file-change commit for historical purposes. The state of the parent kitchen code is at the empty commit (Empty1) with the code from the previous commit (Parent2). The state of the child kitchen code is at the downward merge (Merge1).

Scenario 3: Fix

The user with the child kitchen fixes the problem in the code and commits the change (Child3). A downward merge would have no changes, so the user merges up with the parent once again (Merge3).

Note

Reverted commits are tagged. The kitchen revert process tags the version control commits that it rolls back so commits can be identified in the version control system.

Each kitchen revert generates two tags:

1. pre-revert-<kitchen_name>-<timestamp> to recover from the revert process if needed.

2. post-revert-<kitchen_name>-<timestamp> to label the completed rollback.