Honeydew leverages a Git development workflow to store and manage changes to all semantic layer metadata, backed by a Git repository providing version control. The Git repository can be either provided and managed by the customer, within their Git provider of choice, or hosted by Honeydew. The metadata is stored within the Git repository in an open format (YAML).
Metadata YAML files can be directly edited in any external editor, not just by using the Honeydew Studio UI

​
Git Provider Integration

Honeydew supports integration with all major Git providers. Choose your preferred provider for detailed setup instructions:

​
Git Repository Structure

Different workspaces reside within the same repository as separate folders, each containing their separate semantic layer metadata, environment settings and more.

​
Repository Structure

your-organization-repo/
├── hr-workspace/
│   ├── schema/
│   |   ├── entity1/
│   |   |   ├── attributes/
│   |   |   |   ├── attribute1.yml
│   |   |   |   ├── attribute2.yml
│   |   |   |   └── ...
│   |   |   ├── datasets/
│   |   |   |   └── entity1_dataset.yml
│   |   |   ├── metrics/
│   |   |   |   ├── metric1.yml
│   |   |   |   ├── metric2.yml
│   |   |   |   └── ...
│   |   |   └── entity1.yml
│   |   ├── entity2/
│   |   └── ...
│   ├── domains/
│   |   ├── domain1.yml
│   |   └── ...
│   ├── perspectives/
│   |   ├── dynamic_dataset1.yml
│   |   └── ...
│   └── workspace.yml
├── gtm-workspace/
│   └── ...
└── ...
Each workspace folder contains:
  • schema/: All entities, each with its attributes, metrics, and datasets
  • domains/: Domain configurations and settings
  • perspectives/: Dynamic datasets, including pre-aggregates
  • workspace.yml: Workspace-level settings and configurations, including environments settings
Different workspaces within an organization can share the same Git repository, but maintain complete semantic separation through folder isolation

​
Git-Based Development Workflow

​
Branch-Based Development

Changes in Honeydew are made over branches in Git, following standard development practices:
  1. Branches:
    • Users work on branches for their changes
    • Branches in Git are automatically created when a user creates a new branch for making changes in Honeydew Studio
    • Changes within a branch that are done in Honeydew Studio UI, are scoped to a specific workspace and do not affect other workspaces
    • Branches are shared across all users within a workspace, allowing any user to access and collaborate on any branch
  2. Discarding Changes: At any time, users can discard a branch with all the changes that were made in it
  3. Production Publishing:
    • When users click Publish changes in Honeydew Studio UI, a Pull/Merge Request is automatically created in the Git repository, from the underlying Git branch to the main Git branch.
    • Users can review all the changes they have performed, before publishing.
  4. Merging: Two workflows are supported:
    • The Pull/Merge Request is automatically merged after creation (recommended for evaluation period and small teams)
    • The Pull/Merge Request requires manual review and approval before merging (recommended for production workflows)
    Currently there is no way to configure automatic/manual merging permission per user or per branch. This functionality is coming soon.
    Once merged, the prod version is updated with the new changes and becomes the new shared source of truth for all users and tools that use the semantic model represented by the workspace.
In some cases you would want to manually review and merge Pull/Merge Requests, and not allow automatic merging at any circumstance. This can be achieved by setting branch protection rules in your Git provider to require mandatory review and approval for any Pull/Merge Requests, before merging to the main branch.Additional fine-grained rules, such as code ownership for specific entities/metrics, can be configured at Git provider level, using the Code Owners functionality, or other branch protection policies functionality.

​
Changes history

All changes to the semantic layer metadata are tracked in Git, providing a complete history of every modification. Users can view the history of changes, compare different versions, and revert to previous states if needed.
Currently, reverting changes must be done outside of Honeydew Studio UI, by reverting the relevant commits in Git. Reverting changes from within Honeydew Studio UI is coming soon.

​
Collaboration Features

Honeydew provides real-time collaboration capabilities through shared branch access:
  • Shared Branch Access: Any user can access and work on any branch created by other users, enabling collaborative development on features or analyses
  • Branch-based Collaboration: Teams can create branches for collaborative projects, with multiple users contributing changes to the same branch
  • Change Detection: Users receive status updates when other users make changes to the prod version while they are working on their branch
  • Branch Refresh: Users can refresh their branch with the latest changes from prod, similar to standard Git development flows
  • Conflict Resolution: Honeydew Studio does not provide any dedicate tools for conflict resolution. Standard Git workflows apply for resolving conflicts within any yaml files.
Since Honeydew stores each entity, attribute, metric, dataset, and domain as separate YAML files, the chances of merge conflicts are significantly reduced, even with multiple users working concurrently.

​
Development Workflows

Development flows outside of Honeydew Studio UI can operate directly on the Git repository.

​
Edit files directly

The following use cases can benefit from using a code editor directly on files in the Git repository:
  • Major Refactoring: Large-scale changes can be performed by editing the semantic layer YAML files directly
  • Bulk Operations: Mass updates across multiple entities, metrics, or attributes
  • Automation: Script-based metadata management and deployment
You can run validations on changes in the Git repository by using the Honeydew Snowflake Native Application - you can find an example here.

​
Use with your Git provider capabilities

  • Code Review: Honeydew creates Pull/Merge Requests that can be reviewed within your Git provider UI
  • CI/CD Pipelines: Use Git provider CI/CD capabilities (e.g. GitHub Actions), for automated testing and deployment of semantic layer changes. Automation scripts can call Honeydew programmatically using the Snowflake Native App APIs or GraphQL API
  • Complex conflict resolution: Use your Git tools to handle complex merge conflicts if they happen