Context
MetricFlow, a B2B SaaS company, uses Looker for BI on top of Snowflake and maintains 300+ LookML files plus 1,200 analytics SQL models. Today, analysts edit LookML directly in production and keep SQL scripts in shared folders, causing broken explores, inconsistent metric definitions, and difficult rollbacks.
You need to design a Git-based workflow for managing both LookML and SQL codebases so releases are testable, auditable, and safe for a 25-person data team. The solution should support coordinated changes across dbt models, warehouse objects, and Looker semantic definitions.
Scale Requirements
- Users: 25 contributors, 8-12 PRs/day
- Codebase: 300+ LookML files, 1,200 SQL/dbt models, 150 dashboards
- Deployment frequency: 10 production releases/day
- Validation target: PR checks complete in < 12 minutes
- Recovery target: Roll back a bad release in < 15 minutes
- Warehouse scale: 20TB Snowflake analytics environment
Requirements
- Define a Git branching and promotion strategy for LookML and SQL changes across dev, staging, and prod.
- Ensure PR validation includes SQL linting, dbt tests, LookML validation, and dependency checks before merge.
- Support isolated developer environments so LookML changes can be previewed against branch-specific SQL models.
- Design deployment orchestration so dbt runs before LookML promotion when schema changes occur.
- Include versioning, rollback, and release tagging for coordinated semantic-layer and warehouse changes.
- Add data quality and semantic quality checks to prevent broken dashboards, invalid joins, or renamed fields from reaching production.
Constraints
- Stack is fixed to Snowflake, dbt Core, Looker, GitHub, and Airflow.
- Team has limited platform engineering support; the workflow should be simple to operate.
- Production dashboards serve finance and executive reporting, so failed releases must not break existing explores.
- Compliance requires full audit history of code changes, approvals, and deployments.
