Continuous Deployment to Kubernetes: the First Safe Design

What CD Must Guarantee

A deployment pipeline exists to move an exact artifact into a known environment and then prove that the system is healthy afterward. A good pipeline therefore answers three questions precisely: what binary or image is being deployed, where is it being deployed, and how is success measured? If any of those answers is fuzzy, rollback becomes guesswork and incident debugging becomes archaeology.

For a Kubernetes-based Go backend, the minimum safe guarantees are straightforward. Build one immutable image per service. Tag it with the commit identity and preferably record the digest. Update only the target Deployment. Wait for rollout status to complete. Refuse to call the deploy successful merely because kubectl apply returned exit code 0.

Why This Is Still a Design Spec

The reference meridian repository does not yet contain Dockerfiles, Kubernetes manifests, GitHub Actions workflows, or a migration system. This chapter therefore specifies the first credible deployment design rather than pretending an automated production path already exists. That honesty matters: the educational goal is to teach how such a pipeline should be built from the current repository state, not to describe infrastructure that has not been written yet.

Push-Based vs GitOps

Planned Deploy Assets

Reference Workflow

name: deploy\n\non:\n  workflow_dispatch:\n    inputs:\n      service:\n        type: choice\n        required: true\n        options: [gateway, identity-service, community-service, billing-service]\n      environment:\n        type: choice\n        required: true\n        options: [staging, production]\n\njobs:\n  deploy:\n    runs-on: ubuntu-latest\n    environment: ${{ inputs.environment }}\n    steps:\n      - uses: actions/checkout@v4\n      - uses: docker/login-action@v3\n        with:\n          registry: ghcr.io\n          username: ${{ github.actor }}\n          password: ${{ secrets.GITHUB_TOKEN }}\n      - name: Build and push image\n        uses: docker/build-push-action@v6\n        with:\n          context: .\n          file: ./apps/${{ inputs.service }}/Dockerfile\n          push: true\n          tags: ghcr.io/thesyscoder/meridian/${{ inputs.service }}:${{ github.sha }}\n      - uses: azure/setup-kubectl@v4\n      - name: Apply overlay and wait for rollout\n        run: |\n          kubectl apply -k deploy/k8s/overlays/${{ inputs.environment }}\n          kubectl -n meridian rollout status deployment/${{ inputs.service }} --timeout=180s

Rollback and Safety Gates

Because Meridian has not yet implemented schema migrations, this initial CD design intentionally omits a migration step rather than inventing one. The correct forward plan is to reserve a pre-rollout hook for migrations once a real migrator and backward-compatible schema policy exist. Until then, the pipeline's core safety gates are CI success, protected deployment environments, rollout-status verification, and a practiced rollback path.