Skip to main content

Pull Request Workflow in Holistics

Beta Feature

The PR/MR Workflow is currently in beta:

Introduction​

In a typical development process, when you make changes in the development branch, you need to create a Pull Request (in GitHub) or a Merge Request (in GitLab) before publishing to production. This allows other users to review your changes and triggers the CI workflow for testing and validation.

This step is essential to ensure no downtime and maintain code quality in the production environment.

How PR Workflow works in Holistics​

The PR Workflow in Holistics seamlessly integrates with your GitHub repository to enforce code review practices. This powerful integration streamlines your development process while maintaining quality control.

1. Create PR from Holistics​

When you've made changes and committed them in your Development workspace, Holistics provides a convenient "Create PR" button that takes you directly to GitHub with a pre-filled pull request for your branch.

2. Track PR status​

Once created, Holistics displays the PR status right in your workspace, keeping you informed without switching contexts. You can continue making commits, and they'll automatically update the existing PR.

3. Auto-publish on merge​

When your PR is approved and merged to the master branch in GitHub, Holistics automatically detects this and publishes your changes to production. Your dashboards and reports become immediately available to end users - no manual publish step required.

4. Error handling​

If there are any errors during the auto-publish process, Holistics will notify you and provide options to resolve them before the changes go live, ensuring a smooth deployment experience.

This workflow ensures that all production changes go through proper review while maintaining a smooth, automated deployment process.

How to setup PR Workflow in Holistics​

The setup process depends on your Git provider. Each provider has specific requirements for access tokens and permissions:

Both workflows provide the same core functionality - enforcing code review before production deployment - but use different terminology and authentication methods based on your Git provider.

Using the PR Workflow​

After setting up the workflow for your Git provider, the process is the same regardless of whether you use GitHub or GitLab:

Step 1: Create a Pull/Merge Request​

  1. Make your changes in the Development Workspace and commit them
  2. Click the Create PR button (GitHub) or Create MR button (GitLab) in the top right corner
  3. You'll be redirected to your Git provider to complete the PR/MR creation
  4. Return to Holistics to see the PR/MR status tracked as "Open"

Step 2: Collaborate and iterate​

  • Team members can review your changes and leave comments in your Git provider
  • Continue making commits in Holistics - they'll automatically update the existing PR/MR
  • No need to create new PRs/MRs for additional changes

Step 3: Auto-publish on merge​

  • Once approved and merged to the master branch, changes automatically publish to production
  • If auto-publish fails, use the Publish button in Holistics to retry manually
  • For custom publish logic (e.g., avoiding weekend deployments), use our Publish API

Configure PR workflow required or optional​

Admin can control whether Pull/Merge Requests are mandatory for all changes or optional, giving teams flexibility to balance code review requirements with the need for quick fixes.

How it works​

  1. Default behavior: By default, PR/MR is not required. Users can publish changes directly from Development to Production without creating a Pull/Merge Request.

    Enable PR requirement toggle off

  2. Enabling PR/MR requirement: When you toggle on "Require PR for all changes", every change must go through a Pull/Merge Request before it can be published to production. This ensures all code modifications are reviewed before going live.

    Enable PR requirement toggle on

Configuration steps​

  1. Navigate to Settings > Project Settings > Git Integration
  2. Under the PR/MR Workflow section, locate the "Require PR for all changes" toggle
  3. Toggle it ON to require PRs/MRs for every change, or leave it OFF to allow direct publishing

Impact on workflow​

When PR/MR is NOT required (default):

  • Users can publish changes directly using the "Publish" button
  • Suitable for teams that trust analysts to make small, low-risk changes
  • Faster deployment for urgent fixes

When PR/MR is required:

  • The "Publish" button is disabled
  • Users must create a PR/MR for every change, regardless of size
  • All changes go through review process
  • Better for teams requiring strict change control
Choosing the right setting

Consider your team's needs:

  • Require PRs/MRs: Best for teams with compliance requirements or those wanting strict review processes
  • Keep optional: Suitable for experienced teams who can judge when reviews are needed
Let us know what you think about this document :)