As infrastructure-as-code becomes standard in modern DevOps, the same principles are extending into the world of BI and analytics. Tools like Sisense now support treating dashboards and data sets as code — versioned, reviewed, and deployed just like software. This approach, often called “Dashboards as Code” or “Observability as Code”, enables structured workflows, collaboration, and CI/CD.
This article summarises key learnings from working with Sisense Git integration — aimed at helping others get started faster and avoid common pitfalls. It’s best suited for those who’ve either explored the feature or are ready to implement a version-controlled workflow for dashboards and analytics assets.
Prerequisites:
- Git integration must be enabled in your Sisense environment
- A connected and authenticated Git repository (e.g. GitHub, GitLab, Bitbucket)
- At least one dashboard, chart, or cube added to version control (Git project) and understand the folder structure
Workflow
For a typical Dev->Staging->Prod workflow below:
- Create two Git branches: dev and main
- Point a dedicated Sisense Dev instance to the dev branch
- Use pull requests to merge approved changes from dev to main
- Set up a CI/CD pipeline to deploy changes from main to Staging and Production environments
For Reporting Analysts (Dashboard Creators)
- Work in Dev: Build or update dashboards in the Sisense Dev instance. Add charts, tweak filters, or refine layouts using the visual editor.
- Save to Git: When ready, pushes changes as YAML/SQL files to the dev Git branch.
- Request Review: Open a pull request (PR) from dev to main. Collaborate with data engineers for review.
- Test in UAT: After merge, changes get deployed to the UAT environment. Here, stakeholders validate dashboards with near-final data.
- Deploy to Prod: Once approved, the changes are automatically or manually pushed to Production, making dashboards live for end users.
For Data Engineers (BI Platform Owners)
- Maintain Git Structure: Set up and manage separate Git branches for Dev, UAT, and Prod. Ensure Sisense environments point to the right branch.
- Review PRs: Check for query performance, consistent naming, secure access, and use of reusable snippets/views before merging PRs to main.
- Handle Conflicts: Resolve any merge issues
- Automate Deployments: Use Sisense’s API to push content from Git main to staging and production instances.
- Ensure Data Connection Consistency: Make sure Elasticube and data source names match across environments and are actually connecting to the right data source.
Benefits
- Improved Data Quality & Fewer Production Issues
Version-controlled queries and dashboards reduce accidental errors, ensuring only reviewed changes make it to production. Testing changes in Dev and UAT before release helps catch logic errors, broken filters, or misaligned metrics early. - Consistent Definitions
Shared YAML/SQL assets eliminate the risk of inconsistent logic across environments or dashboards. P.S. This is the only way to keep Dashboard and Cube IDs consistent across multiple Sisense instances so far. - Collaborative Development
Analysts and engineers can work together using branches and pull requests — encouraging peer review and shared ownership. Analysts can you the Sisense UI they are familiar with to make safe changes in Dev Sisense. Engineers can make use of the json code files to enable automations and workflows. - Faster Rollbacks
If a mistake does reach production, Git history makes it easy to identify and revert to a known good state. - Auditability & Traceability
Every change is tracked — helpful for compliance, debugging, or understanding the evolution of KPIs over time.
Pitfalls
- Data Connection Consistency
If Elasticubes are used, ensure data connection names are consistent across environments. Mismatches can cause sync or deployment failures. - Merge Conflicts Across Instances
Conflicts may occur when merging from main to staging or production Sisense instances—often caused by local, manual changes in those environments. To resolve, either manually fix conflicts or discard pending changes. Best practice: avoid making direct changes in production Sisense instances. - Collaboration Overhead
When multiple BI analysts work on the same Git-connected project, coordination becomes critical. Without agreed workflows (e.g. feature branches, PRs, naming conventions), it’s easy to overwrite each other’s changes or introduce conflicts. - CI/CD Automation via API
While Sisense provides APIs to automate deployments, no official SDKs or wrapper libraries exist. You’ll need to build and maintain your own scripts to integrate Git workflows with CI/CD pipelines.
Hope this helps others get started and level up their workflow, collaboration, and data quality with or without Sisense 🙂
Original article can be found on my medium : https://medium.com/@chaobioz/dashboards-as-code-with-sisense-git-integration-71bcb0957721
