How do you analyze source control, CI/CD, and feature flag data in Metabase?
Source control, CI/CD, and feature flag tools like GitHub and Jenkins hold the record of how code becomes production. To analyze them in Metabase, you sync each tool into a database and map its objects to a shared model of change requests, pipeline runs, deployments, and flag changes. Metabase has no native connector for these tools, so the sync comes first.
TL;DR — Pull requests, merge requests, pipeline runs, and deploys have the same shape in every tool. Model
pull_requests, pipeline_runs, and deployments once, key them on the commit sha where the tool exposes it, and pipeline-health dashboards port across tools. DORA also needs deployments, which the GitHub and GitLab guides model directly. Which tools does this cover?
This pattern applies to source control, CI/CD, and feature flag tools, including:
- Azure DevOps — work items, pipeline runs, and pull requests
- Bitbucket — pull requests, PR activity, and Pipelines runs
- Buildkite — builds, jobs, and test executions
- CircleCI — workflow runs, jobs, test results, and credit usage
- GitHub — pull requests, reviews, commits, workflow runs, and deployments
- GitLab — merge requests, approvals, pipelines, and deployments
- Jenkins — builds, stages, and test results
- Feature flags & experimentation
- LaunchDarkly — flags, flag changes, and experiment results
- Statsig — experiments, gate changes, and Pulse results
The same model fits other CI/CD and deploy tools, such as TeamCity, Travis CI, and Argo CD. For the planning side, see issue tracking.
What is the shared software delivery data model?
| Concept | Common terms | Used for |
|---|---|---|
| Repository | Repository, project | Scope and ownership |
| Change request | Pull request, merge request | PR cycle time and throughput |
| Review | PR review, MR approval | Review latency |
| Commit | Commit sha | The join key from code to deploy |
| Pipeline run | Workflow run, pipeline, build | Build success rate, duration |
| Job / stage | Job, stage, step | Bottlenecks, queue time |
| Test result | Test result, test execution | Flaky tests, pass rate |
| Deployment | Deployment, release | Deployment frequency, lead time |
| Flag change | Audit-log entry, gate change | Rollout activity, change failure |
| Person | User, actor, triggered_by | Bot exclusion |
The most important field is the commit sha that links a change request to the pipeline runs that built it and the deployment that shipped it. Without it, lead time and change failure rate can’t cross tools. Several tool guides’ minimal models leave it out, so add it (head_sha, commit, sourceVersion) when you sync runs. Put the default-branch and bot filters in the model too, so every dashboard counts the same work.
How do you connect software delivery tools to Metabase?
- Pipeline route — sync each tool into a database on a schedule with Airbyte, Fivetran, dlt, or its REST or GraphQL API, then build dashboards on the modeled tables. See our guide to building a data pipeline.
- MCP + CLI route — pull a scoped slice through the vendor’s MCP server, save it as CSV, and load it with
mb upload csv. Good for exploration; it keeps no history.
Per-tool setup lives on each guide above.
What can you analyze across these tools?
- DORA metrics — the four delivery measures, read together
- Deployment frequency — production deploys per day or week
- Lead time for changes — first commit to running in production
- Change failure rate — share of deploys that cause an incident or rollback
- MTTR — time to restore service after a failed change
- Cycle time — work started to done; for pull requests, open to merge
- Build success rate — passing runs on the default branch
- Pipeline duration — median and p90 run time
- Queue time — wait before a job gets a runner or agent
- Flaky test rate — tests that pass and fail on the same commit
- Test pass rate — passing test executions per run
Which dashboards should you build?
- Software delivery dashboard — throughput, cycle time, and deploys in one view
- DORA metrics — the four measures, trended by team and service
- CI pipeline health — success rate, duration, queue time, and flaky tests
- Code review health — review latency, PR size, and review load
- Release quality — failed deploys, rollbacks, and incidents per release
- Feature flag rollout — flag changes and rollouts next to deploys
Related dashboard guides: DevOps, release management, QA automation, and engineering teams.
Common mistakes
Counting every branch. → Feature-branch runs and merges inflate throughput and success rates. Restrict flow and DORA metrics to the default branch.
Leaving bots in contributor metrics. → Dependabot and Renovate open a lot of pull requests. Flag bot accounts in the person table and exclude them by default.
Averaging durations. → One stuck pipeline or a PR left open over a holiday skews the mean. Report median and p90.
Syncing raw build logs. → Logs are large and rarely queried. Land runs, jobs, and test results, and leave logs in the CI tool.
Reporting DORA without incident data. → Change failure rate and MTTR need incidents joined to deploys. Without them, only half of DORA is real.
Related
Analytics
Integrations
FAQ
Does Metabase connect natively to GitHub, GitLab, or Jenkins?
No. Metabase reads SQL databases and warehouses, not SaaS APIs. Sync the tool into a database with Airbyte, Fivetran, dlt, or its API, then connect Metabase to that database. For quick exploration, pull a scoped slice through the vendor’s MCP server, save it as CSV, and load it with
mb upload csv.How do I compute DORA metrics across source control and a separate CI tool?
Deployment frequency comes from deployments alone; lead time joins those deployments to commits and pull requests on the commit
sha, whichever tool ran the deploy. Change failure rate and MTTR also need incident data — from PagerDuty or a similar tool — joined to those deploys. See DORA metrics, lead time for changes, change failure rate, and MTTR.Where do issue trackers and feature flags fit?
Issue trackers (Linear, Jira, Shortcut) have their own issue tracking overview. Azure DevOps lives here because it spans Boards, Repos, and Pipelines. Flag and experimentation tools are a subcategory: feature flags & experimentation. Both join to delivery data on deploys and releases.
How is this different from the software delivery analytics overview?
This page covers the tools and the shared model they map onto. The software delivery analytics overview covers which metrics matter and how to run the practice.