Conrad DevOps

CI/CD pipeline

How a change reaches Conrad's production — GitLab CI tests and lint, Kaniko builds the image, assets go to Cloud Storage behind the CDN, Terraform reads secrets and applies the Helm release, and GKE rolls out the pods — plus image tags, deploy ordering and build-once runtime configuration.

From the CI/CD, Terraform, Helm and "whole flow" parts of your Conrad DevOps note.

Know

  • The flow: code → GitLab CI (tests, lint) → Kaniko builds the image → registry → _nuxt assets to Cloud Storage for the CDN → Terraform (secrets from Secret Manager, Helm release) → Helm fills the chart → Kubernetes pulls the image and rolls out the pods.
  • Kaniko: builds images without a Docker daemon or root, which matters on shared CI runners. The upstream repository was archived in June 2025; Chainguard maintains a fork, and BuildKit (rootless) and Buildah are the usual successors.
  • Assets: app.cdnURL (runtime config NUXT_APP_CDN_URL) makes the HTML reference the CDN; upload before rollout, never delete old builds during a deploy.
  • Image tags: the commit SHA, immutable and traceable, and the value Helm changes per deploy.
  • Build once: environment-specific values and secrets arrive at runtime through Helm and runtimeConfig, never baked into the image.
  • Preview environments: one Helm release per merge request (mr-123.preview.… on wildcard DNS), declared as a GitLab environment with on_stop and auto_stop_in, pointed at shared staging backends, torn down with helm uninstall on merge or close.
  • Nx generators: scaffolding in code: a new app gets the agreed files, extends the shared layer and is registered in the workspace; generators also change existing projects, which is how a platform team rolls out conventions.
  • Tests and environments: type check and lint first, then unit and component tests (Vitest), Nitro integration tests and Playwright end-to-end; staging deploys on every merge to main, production on a git tag that promotes the same image.

Fact check of your notes

Gotcha· Kaniko is archived

Your notes describe Kaniko correctly. It is worth knowing that Google archived the project in June 2025: if they still use it, ask whether a move to BuildKit or a maintained fork is planned, rather than presenting it as a problem.

Exercise

Exercise
  • Say the whole flow out loud in 90 seconds, naming what each tool is responsible for.
  • Write the Kaniko job and a helm upgrade --install --atomic --set image.tag=$CI_COMMIT_SHA deploy job from memory.
  • Decide what you would answer if they ask how you would make deploys safer: asset publishing order, canaries through Istio, --atomic rollbacks.

Be able to say

Be able to say· Walk us through your deployment pipeline.

"GitLab CI runs the tests and the linter, then Kaniko builds the image without root privileges and pushes it tagged with the commit SHA. CI also uploads the hashed _nuxt assets to Cloud Storage for the CDN, so pods only render HTML. For the deployment, Terraform reads the secrets from Secret Manager and applies the Helm release, Helm fills the chart with the new tag and this environment's values, and Kubernetes rolls out new pods next to the old ones, sending them traffic once their readiness checks pass."

Be able to say· What can go wrong during a storefront deploy, and how do you prevent it?

"For a while two versions serve traffic side by side, and cached HTML and open tabs still point at the old build's chunks. So assets are published before the pods roll out and old ones are kept for days, the HTML cache is versioned or purged so stale pages don't outlive their assets, Nuxt reloads the page when a chunk fails to load, and API changes stay backward compatible during the overlap. On top of that: images tagged by SHA for instant rollbacks, health checks gating traffic, and canaries for risky changes."

Your notes

Open in Notes

Nothing yet. Notes filed here show up on this page and the section overview.