Workspace management in Development

Introduction

Holistics organizes your BI content into two workspace types:

• Public workspace: your company's shared dashboards, datasets, and models.
• Personal workspace: each member's private space for their own dashboards and experiments. Admins can browse everyone's personal workspaces through Members' Spaces in Reporting.

Underneath, dashboards in both workspaces are code files under Git version control. For day-to-day work you never notice this: you create, edit, and delete dashboards directly in Reporting, and Holistics commits the changes to the underlying branch for you.

Development is for the work Reporting cannot handle: mass refactoring (say, renaming a metric that dozens of dashboards use) and other as-code workflows, for both workspaces. This page explains how each workspace maps to Git branches, and what that means when you refactor shared models.

Workspaces and their branches

Each workspace is backed by its own set of Git branches. The table below shows what each branch does.

Workspace	Branch	Role
Public workspace	master	Production. What end users see in Reporting. Holds dashboards, datasets, and models.
	Dev branches (user-a-dev, feat-b, ...)	Make changes to the public workspace without affecting production. Publishing merges them into master.
Personal workspace	members-spaces/prod	Live personal dashboards, exactly as members see them in Reporting. Read-only, dashboards only.
	members-spaces/dev	Edit personal dashboards in Development. Publishing merges into members-spaces/prod.

The diagram below shows how the branches relate. Publishing a normal dev branch merges it into master. Publishing members-spaces/dev merges it into members-spaces/prod. Reporting reads from both sides: public dashboards come from master, and personal dashboards come from members-spaces/prod.

How workspaces map to Git branches

• Public workspace
• Personal workspace (Members' Spaces)
• Reporting
• Development
• development branches
• user-a-dev — A member's development branch, created from master
• feat-b — A feature branch, created from master
• master (production) — Dashboards, datasets, and models as code. This is what production and members-spaces read from.
• read-only
• you edit here
• members-spaces/prod — Read-only. Mirrors exactly what members see in Reporting. Updated automatically whenever anything is published to master. Dashboards only, no datasets or models.
• members-spaces/dev — Where you edit personal dashboards in Development. Holds uncommitted changes.
• Public workspace — What end users see in the public workspace. Comes from the master branch.
• Personal workspace — What members see in their own personal workspaces. Comes from the members-spaces/prod branch.

• master → dev-a (branch off)
• dev-a → master (publish (merge))
• dev-b → master
• master → ms-prod (auto-updates on every publish)
• ms-dev → ms-prod (publish (merge))
• rep-public → master (reads from)
• rep-personal → ms-prod (reads from)

Branching and publishing follow the standard Git workflow in Holistics. If your branch is behind master when you publish, Holistics pulls master into it first, then merges. See Branch management for creating and deleting branches.

The members-spaces branches contain only dashboards. The datasets and models those dashboards use live on master, and personal dashboards read from it directly. When you publish, they pick up the new production code right away, with no merge step in between.

Refactoring across workspaces

Mass refactoring (renaming a metric, deleting a field, renaming a model) happens in Development on a development branch. Because public and personal dashboards live on different branches, you fix them at different points. The diagram below shows the full flow, and the two sections after it cover each half.

Refactoring across workspaces

• 1. Work on your dev branch — Refactors happen in Development on a dev branch, never directly on master.
• 2. Rename or delete a metric — For example, renaming a model field or deleting an unused metric.
• 3. Public dashboards break. Fix them immediately — Syntax errors surface immediately on your branch for every public dashboard the change breaks.
• 4. Publish to master — Your refactor goes live. Public dashboards are already fixed.
• 5. Personal dashboards break — members-spaces/prod reads directly from master, so personal dashboards using the old names break. This window is expected.
• 6. Check out members-spaces/dev — Personal dashboards can only be edited on this branch.
• 7. Fix and publish to members-spaces/prod — Your fixes merge into members-spaces/prod. Personal dashboards work again in Reporting.

• s1 → s2
• s2 → s3
• s3 → s4
• s4 → s5 (downtime starts)
• s5 → s6
• s6 → s7

Fix public dashboards before you publish

Public dashboards live on the same code base as your models. If your refactor breaks one of them, you see the syntax error right away on your development branch. Fix every affected dashboard there and publish everything together, so nothing broken reaches production.

Fix personal dashboards after you publish

Personal dashboards live on the members-spaces branches, so your development branch cannot touch them. You fix them right after publishing:

1. Publish your development branch to master.
2. Personal dashboards that used the renamed or deleted field now break, because members-spaces/prod reads directly from master. This short broken window is expected.
3. In Development, check out the members-spaces/dev branch.
4. Fix the broken dashboards. The same syntax errors show up there.
5. Publish. Your fixes merge into members-spaces/prod, and the dashboards work again in Reporting.

info

You cannot fix personal dashboards before publishing because they live on separate branches. Your refactor only reaches them once it lands on master.

Why personal dashboards are isolated

Keeping personal workspaces out of the publish workflow is a deliberate choice. A member's experimental dashboard can never block a production publish, and unreviewed content never lands on master.

The trade-off is the short broken window after a refactor, until you fix personal dashboards on members-spaces/dev. Keep anything your team depends on in the public workspace, where every publish validates it.

FAQs

What happens when I publish from a dev branch to master?

Three things, in order:

1. Holistics merges your branch into master, pulling master into it first if it is behind. The changes go live for the public workspace.
2. The members-spaces branches record the new master reference. You will see this as an "Update public_workspace..." commit on them.
3. Personal dashboards now read the new production code. If your publish renamed or deleted something they use, they break at this point. Fix them on members-spaces/dev, as described in Fix personal dashboards after you publish.