Skip to main content

Code Review Process

Introduction

After connecting to an external Git repository, to make full use of your new setup, you can enforce a pull request & code review process.

Example workflow with Code Review

Aside from the steps in the default workflow with version control in Holistics, the code review process should happen before Publish.

The workflow when using AML studio with External Git repository

In Development, after a data developer Commit their code, instead of clicking Publish to production right away, they should go through the code review process as follows:

  1. The data developer goes to the external Git repository, and creates a Pull Request (PR), then asks for a review from another team member.
  2. If the PR is approved, the developer merges the PR to the master / main branch. Then go back to Holistics Development and click Publish to Production.
  3. If the reviewer requests some changes, the developer should go back to Holistics Development, modify as requested, and push again.

How to enforce the Code Review process

Currently, Holistics has not implemented an internal code review feature similar to that of GitHub/GitLab, and users can publish directly to production right after committing.

To make sure the changes must go through a review before publishing, you can use the Branch Protection feature of GitHub / GitLab. For example, in GitHub:

  1. Go to your GitHub repository, go to Settings -> Branches -> Add branch protection rule. Input master to the Branch name pattern field, and select any protection rule you need. Require a pull request before merging is a must.

  2. Now you will not be able to to publish to production without first creating a Pull Request (PR). In this step, you must use option Create a merge commit instead of Squash and merge or Rebase and merge.

    The reason is that our Git Actions depend on Commit History. Thus, if you use either Squash and Merge or Rebase and merge methods, the commit history is modified so that Holistics cannot detect if the published commit is merged to master or not.

    Merge Pull Request

  3. After the PR has been successfully merged to master, you have 2 options to Publish your changes to Production:

    a. Manual approach: return to Holistics and click Publish to Production.

    b. Auto-publish: or you can leverage our Publish API to auto Publish your changes whenever your PR is merged to master (via your GitHub)

Here is a video demonstrating the whole process (using Manual Approach):

You can learn more about this process via the official docs of the Git providers:


Let us know what you think about this document :)