Architecture
A team deployment is a small set of services that run alongside your CI. This page describes what runs where and how the parts talk to each other.
Components
- pytest plugin runs inside each CI worker. It instruments the test process and writes spans, logs, and coverage directly to ClickHouse over mTLS, and uses the KV store for parallel-worker coordination. The plugin also queries the web API for test selection; that path is omitted from the diagram for clarity.
- Web console serves the UI and the API used by the dashboard and the
zbCLI. - KV store holds short-lived coordination state used by the plugin (worker leases, work-stealing queues).
- Janitor runs background ClickHouse cleanup and managed version updates.
- ClickHouse holds spans, logs, jobs, configs, users, and permits.
All connections from CI runners to DAGZ services use mTLS.
The plugin's certificate is provisioned through a TLS secret in the CI runner's namespace (the userNamespace Helm value).
Trust boundaries
- Browser ↔ web console: HTTPS plus an Entra (or Google) OIDC ID token, validated server-side. See SSO with Microsoft Entra ID.
- CI runner ↔ web / KV / ClickHouse: mTLS using the per-namespace certificate the chart deploys.
zbCLI ↔ web console: a 90-day client certificate issued by the deployment after a one-time browser sign-in.
What lives where
| Concern | Location |
|---|---|
Per-project config (uri, public_url, feature flags) | .dagz/config.yaml in your repo |
| Per-machine daemon settings | ~/.dagz/local.env/daemon.yaml |
| Auth provider config (Entra/Google) | DAGZ ClickHouse configs table |
| Permits (who can sign in) | DAGZ ClickHouse permits table |
| Test history, spans, logs, coverage | DAGZ ClickHouse |