CD

Continuous DeliveryCopy Anchor Link

Each app repository builds its Docker image and publishes it to GHCR with the latest tag (see CI). That's where the app pipeline stops: it doesn't touch the polinetwork-cd repository.

Continuous DeploymentCopy Anchor Link

We rely on Flux to deploy our pods following the manifests in the main branch of polinetwork-cd. Flux continuously compares the cluster with the repository and applies any difference, so a merged PR in polinetwork-cd reaches production within minutes.

New images don't need a commit: when a new latest image is published, GitHub calls a Flux webhook, Flux resolves latest to the new image digest and rolls out the deployment. If the webhook is missed, Flux checks for new images every 6 hours anyway.

Our deployments use rolling updates with maxUnavailable: 0: Kubernetes starts the new pod, waits for its readiness probe, and only then stops the old one, so a broken image doesn't take the app down. Stateful services (databases, Redis, Grafana) use the Recreate strategy instead, because only one pod at a time can write to their volume.