# Pipelines

> From git push to live URL; rolling, canary, blue/green strategies, health-gated phases, auto-built images, and audit trail on every deploy.

Source: https://zop.dev/docs/zopday/pipelines

---

## What a pipeline is

A ZopDay pipeline is the path a commit takes from your git branch to a live URL on your Kubernetes cluster. It encapsulates the build, the manifest rendering, the deploy strategy, the health gates, and the rollback handle; **all one pipeline, no separate tools to chain.**

This is the same pipeline you run in the [Quickstart](https://zop.dev/docs/zopday/quickstart) and see per revision in [Deployments](https://zop.dev/docs/zopday/concepts/deployments); this page describes it in full.

![A ZopDay service detail drawer showing the live revision (commit, image, deployed-by) and git source (repository, branch, root directory) for a deployed app service, with a Revisions history tab](https://storage.googleapis.com/zopdev-blog-resources/1/files/originals/20260707/e8e4c02b-e161-4d73-9573-f1ade524289d-pipelines.png)

*A deployed service's live revision; the commit, image, and source the pipeline shipped, with a Revisions history tab for rollbacks.*

Every trigger is tied to an environment policy: push, branch, webhook, or manual UI action. No drift between what your CI does and what ships.

## Pipeline phases

```
Trigger → Build → Render manifests → Pre-flight → Deploy → Gate → Live → Audit
```

1. **Trigger.** Git push, branch event, webhook, or a manual deploy in the UI. Each trigger maps to an environment via your repo configuration.
2. **Build.** **No Dockerfile required**: ZopDay uses Railpack to detect the language and auto-build a container image. If you ship a Dockerfile, it's respected and used as-is.
3. **Render manifests.** Helm renders the release with values merged from base + environment + branch overrides.
4. **Pre-flight.** Image vulnerability scan, manifest lint, policy check (Pod Security Standards, Network Policy), available capacity check.
5. **Deploy.** The chosen strategy applies; rolling, canary, or blue/green. Strategy is switched per service with **no Helm rewrites**.
6. **Gate.** Health gates poll readiness, probes, and any custom SLO. A regression halts the deploy and queues a rollback.
7. **Live.** Once gates pass, traffic shifts to the new version. The live URL is shown in the pipeline view.
8. **Audit.** Actor, action, timestamp, request body; captured to the append-only audit log and forwardable to your SIEM.

## Deploy strategies

### Rolling (default)

Replaces pods in batches sized by `maxSurge` / `maxUnavailable`. Best for stateless workloads with backwards-compatible changes. Fastest to fully roll out, lowest infra cost.

### Canary

Splits traffic to the new version progressively. 1% → 5% → 25% → 100% by default. Each step is gated by readiness + your custom SLOs. A regression halts at the current step and rolls back to the previous version with full traffic.

The `strategy` fields below live in your service's deploy configuration in ZopDay; switching strategy is a config change, not a Helm rewrite.

```yaml
strategy:
  type: canary
  steps: [1, 5, 25, 100]
  pauseSeconds: 120
  slo:
    - metric: http_5xx_rate
      threshold: 0.5%
      window: 60s
    - metric: latency_p99
      threshold: 800ms
      window: 60s
```

### Blue / Green

Stands up the new version alongside the current one with **zero shared state**. Once gates pass, the service selector flips atomically. Old replicas remain warm for the configured grace window so rollback is instant.

```yaml
strategy:
  type: bluegreen
  grace: 10m
  smokeTests:
    - name: api-health
      url: https://api.svc.internal/healthz
      expect: 200
```

## Health gates

Every phase ends in a gate. Gates are pass/fail predicates evaluated against:

- **Pod readiness**: every pod must be `Ready` within the configured window.
- **Probe latency**: `livenessProbe` and `readinessProbe` round-trip time.
- **Custom SLOs**: any Prometheus or Datadog metric, evaluated as a predicate. The metric source is wired to your environment in ZopDay before a gate can reference it.
- **Smoke tests**: HTTP / gRPC health checks against the new version's URL.

A failing gate halts the deploy at the current step and triggers a rollback to the previous known-good version. **Halt, surface the cause, roll back**: that's the contract.

## Secrets handling

Sensitive env vars never live in ZopDay. They are masked in the UI and stored in your cloud-native secret manager:

- **AWS**: Secrets Manager.
- **GCP**: Secret Manager.
- **Azure**: Key Vault.

ZopDay reads from the vault at deploy time using the cluster's IRSA / workload identity / managed identity. The control plane never sees the secret value.

## DORA visibility

Every pipeline emits the four DORA metrics; deploy frequency, lead time for changes, change failure rate, mean time to restore. They show up on the pipeline overview and can be exported per-team, per-service, per-month.

## Triggers

Every pipeline supports four trigger sources:

- **Push**: auto-deploy on push to a configured branch.
- **Branch**: auto-deploy on branch create / merge.
- **Webhook**: external system (GitHub Actions, Jenkins, custom) hits the ZopDay webhook URL with a signed payload.
- **Manual**: a reviewer clicks **Deploy** in the UI.

Each trigger source can be enabled or disabled per environment; for example, push deploys to `dev`, manual-only for `prod`.