# Canary Helm Template

Generated Railiance overlays include a stage-aware Helm chart for Stage 2
canaries and Stage 3 stable promotion.

The chart keeps stable and canary release identities explicit:

- `railiance.stableRelease` names the current stable release;
- `railiance.canaryRelease` names the Stage 2 candidate release;
- `railiance.stage` selects the rendered identity, labels, and selectors;
- `railiance.previousStable` records rollback context before promotion.

## Traffic Shape

The default Stage 2 values use an isolated canary ingress:

```yaml
railiance:
  stage: canary
  traffic:
    mode: isolated

ingress:
  enabled: true
```

This creates canary Deployment, Service, and Ingress resources without changing
the stable release. For environments that use Traefik weighted routing, set:

```yaml
railiance:
  traffic:
    mode: weighted
    provider: traefik
    stableWeight: 95
    canaryWeight: 5
```

The chart then renders a `TraefikService` and `IngressRoute` that split traffic
between the stable and canary services. Other ingress controllers can use the
same stable/canary values layout with controller-specific annotations or a later
provider template.

## Observability And Safety

Generated workloads include:

- Prometheus-compatible scrape annotations on pods and services;
- readiness and liveness HTTP probes;
- conservative resource requests/limits for single-node clusters;
- separate `values/stage2-canary.yaml` and `values/stage3-production.yaml` so
  canary exposure and stable promotion can be reviewed independently.

Run `tests/stage2-template.sh` in the overlay repo before any Stage 2 attempt.
It verifies the scaffold and runs `helm template` when Helm is available.