feat(chart): opt-in Argo Rollouts (blue-green) + pre-deploy migration Job

[nicacioliveira]

Summary

Two opt-in flags in the studio Helm chart so consumers can switch from the default Deployment to an Argo Rollouts Rollout (blue-green or canary), and move DB migrations out of pod startup into a dedicated pre-sync Job.

Both default to off — existing installs keep the exact same Deployment with the on-startup migration path. No selector / label changes, no PVC churn.

What's new

• `argoRollouts.enabled` — render a `Rollout` (argoproj.io/v1alpha1) instead of `Deployment`. Pod template is shared via the new `chart-deco-studio.podTemplate` helper so the two workload kinds describe an identical pod surface. Supports `blueGreen` (default) and `canary` strategies.

• `migrationJob.enabled` — render a Job that runs `bun run --cwd=apps/mesh migrate` ONCE before pods start. Carries BOTH `helm.sh/hook: pre-install,pre-upgrade` and `argocd.argoproj.io/hook: PreSync` annotations so it sequences correctly whether installed via `helm upgrade` directly or synced by ArgoCD. The runtime pod command gets `--skip-migrations` appended (the studio CLI already exposes this flag — see `apps/mesh/src/cli.ts`), eliminating the race between N replicas migrating concurrently and giving a clear pre-deploy gate: migration Job fails → release aborted.

Files

File	Change
`templates/_pod-template.tpl`	new — shared pod template helper + `podCommand` helper that appends `--skip-migrations` when migrationJob is on
`templates/deployment.yaml`	wraps in `{{- if not argoRollouts.enabled }}` and references the helper; lifts `spec.template` body out
`templates/rollout.yaml`	new — gated on `argoRollouts.enabled`, blueGreen by default; mutual-exclusion `fail` for both-on configs
`templates/migration-job.yaml`	new — gated on `migrationJob.enabled`. Sync-wave -1, dual helm + ArgoCD hooks, bounded backoffLimit/activeDeadlineSeconds/TTL
`templates/service-preview.yaml`	new — preview Service for blue-green; Argo Rollouts manages its selector
`values.yaml`	adds `argoRollouts` and `migrationJob` blocks; both off by default

Why opt-in

The chart is open-source and not every consumer has the argo-rollouts controller installed. Defaulting to Deployment keeps zero requirements on the consumer's cluster. Internal CD (deco-apps-cd) flips both flags on for the deco-studio / deco-studio-stg releases — that's a separate change.

Important: migration discipline note

Blue-green amplifies the schema/code overlap window. The Job moves migrations to a single execution point BEFORE the new ReplicaSet probes, but it does NOT make destructive DDL safe — the old (blue) ReplicaSet still serves traffic during the overlap window with the migrated schema. Destructive changes (DROP/RENAME/type changes) still require expand-contract discipline at the migration code level. This is independent of the chart and is being handled team-side as a code/review practice.

Test plan

• `helm lint deploy/helm/studio` passes
• Default render (no flags) produces the same workload surface as before:
  • Deployment with command `bun run deco --no-local-mode`
  • No Rollout, no preview Service, no migration Job
• `helm template ... --set argoRollouts.enabled=true --set migrationJob.enabled=true` produces:
  • Rollout with `blueGreen` strategy, `activeService: deco-studio`, `previewService: deco-studio-preview`, `scaleDownDelaySeconds: 30`, `autoPromotionEnabled: false`
  • Preview Service
  • Migration Job with PreSync hooks and `bun run --cwd=apps/mesh migrate` command
  • Pod command has `--skip-migrations` appended
• Canary mode renders (`--set argoRollouts.strategy.blueGreen.enabled=false --set argoRollouts.strategy.canary.enabled=true`)
• Reviewer: install into a test cluster, verify the Rollout transitions correctly through preview → promotion

---

Summary by cubic

Adds opt-in Argo Rollouts (blue-green/canary) to the studio Helm chart via a shared pod template. Off by default; keeps the Deployment path unchanged and drops the previously proposed migration Job.

• New Features

  • argoRollouts.enabled: renders a Rollout (argoproj.io/v1alpha1) instead of a Deployment; blue-green by default, canary supported.
  • Preview Service for blue-green; Argo manages active/preview selectors.
  • Shared _pod-template.tpl so Deployment and Rollout use the same pod spec.

• Bug Fixes

  • HPA targets the Rollout when rollouts are enabled; otherwise the Deployment.
  • Install fails if both or neither of blue-green/canary are enabled.
  • Honors terminationGracePeriodSeconds: 0 via hasKey check.

^{Written for commit b78e0e3. Summary will update on new commits.}

[cubic-dev-ai]

5 issues found across 6 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="deploy/helm/studio/templates/deployment.yaml">

<violation number="1" location="deploy/helm/studio/templates/deployment.yaml:1">
P1: Enabling Argo Rollouts removes the Deployment, but HPA still targets Deployment, leaving autoscaling with an invalid target.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: Enabling Argo Rollouts removes the Deployment, but HPA still targets Deployment, leaving autoscaling with an invalid target.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At deploy/helm/studio/templates/deployment.yaml, line 1:

<comment>Enabling Argo Rollouts removes the Deployment, but HPA still targets Deployment, leaving autoscaling with an invalid target.</comment>

<file context>
@@ -1,3 +1,4 @@
+{{- if not (and .Values.argoRollouts .Values.argoRollouts.enabled) }}
 apiVersion: apps/v1
 kind: Deployment
</file context>