DataKitchen DataOps Documention

Revert Merges

While users create temporary kitchens as experimental sandboxes, a DataKitchen customer implementation likely has kitchens designated as development and production environments. Merges into these environments are considered deployments and must be carefully controlled. For this reason, the platform offers a way to revert a kitchen to a previous stable state when updates are deemed to be defective.

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

The Revert Kitchen feature reverts the kitchen to the immediate previous state, one state at a time, from most recent to oldest.

Use Revert Kitchen with Caution!

Note that the Revert Kitchen feature to rollback previous updates and merges can be dangerous! The revert should be used only with extreme caution!

Revert a Kitchen Merge or Update

Prerequisite

  • You must be a member of a kitchen's staff to revert any kitchen to a previous state.

Web App Instructions

  1. Click the HISTORY link in the green toolbar to access the Kitchen History page.
  2. Click the Revert kitchen to previous state link.
  3. On the Revert Kitchen page, preview the changes that will result from the revert action.
    • Summary of updates: Provides counts for the number of updates, changed files, recipes, and authors involved in the revert.
    • Summary of file changes: Highlights the specific code changes in the latest update or merge that will be rolled back.
  1. Click the Revert Kitchen button.
  2. In the confirmation dialog, click the Revert button.
  3. Check the kitchen history again to confirm that the latest update is now gone.
    • If reverting a single update, the history no longer lists that update.
    • If reverting a merge, the history removes the merge and, instead, displays a no-file-change commit, to show a record of the revert process with information of what has been rolled back.

Command Line Instructions

  1. Use the kitchen-history command to view the latest changes in the kitchen.
    Alternatively, view the Kitchen History in the web app.
  2. You can use the count option for this command to reduce the output to the latest X commits.
~ $ dk kitchen-history --kitchen test_kitchen --count 3
~ $ dk kitchen-history --k test_kitchen --c 3

Output: kitchen-history command

YYYY-MM-DD HH:MM:SS - Getting kitchen history for kitchen test_kitchen.
--
author  : [email protected]
date    : 2020-06-23T15:55:35Z
message : Merge from feature_kitchen to test_kitchen
sha     : adcfa6aae8ee7935881e1bd3a151efed5cbd033d
--
author  : [email protected]
date    : 2020-06-23T15:36:44Z
message : Files updated in recipe 'parallel-recipe-test': C3
sha     : f2051eccf2b08b1098e3b7ca2b2b94190f5e46d9
--
author  : [email protected]
date    : 2020-06-23T15:16:13Z
message : Merge from test_kitchen to feature_kitchen
sha     : f57fa041595b0371db84a8267d2825a43b8de0a9
  1. Use the kitchen-revert command to roll back the latest update or merge.
~ $ dk kitchen-revert --kitchen test_kitchen
~ $ dk kr --k kitchen_name

Output: kitchen-revert command

YYYY-MM-DD HH:MM:SS - Reverting kitchen test_kitchen to previous state. Local files will not change.
After this operation, run recipe-get -o in the related recipes.
Done!
  1. Check the kitchen history again to confirm that the latest commit is now gone.
    • If reverting a single update, the history no longer lists that update.
    • If reverting a merge, the history removes the merge and, instead, displays a no-file-change commit, to show a record of the revert process with information of what has been rolled back.

Revert Process

Develop and Deploy Scenario

A user creates a child kitchen and commits two updates within it. 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 to the child kitchen. Then the user merges the child kitchen up (Merge2) to the parent. A subsequent change gets committed in the parent kitchen (Parent3).

Revert Scenario

A data engineer discovers that there is an issue in the parent branch and wants to revert changes until all recipe variations run cleanly again. She is unsure where the problem was introduced.

First, the data engineer issues a kitchen-revert command on the parent kitchen to place that kitchen into the previous state, before the the most recent update (Parent3). Her testing reveals that the problem still exists, so she issues a second kitchen-revert command 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).

Fix Scenario

The user in 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 to the parent once again (Merge3).

Reverted Commits Tagged

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

Each kitchen revert generates two tags.

  • pre-revert-<kitchen_name>-<timestamp> to recover from the revert process if needed
  • post-revert-<kitchen_name>-<timestamp> to label the completed rollback

Updated about a month ago

Revert Merges


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.