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 and see per revision in Deployments; this page describes it in full.

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.

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.

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.