spb/ultra-sharp-agent-skills Public

1---2name: shipping-with-ci-cd3description: Designs CI/CD pipelines that ship safely — fail-fast stages, build-once artifact promotion, rolling/blue-green/canary deploy strategies, automated rollback, and backward-compatible migrations. Use when the user asks to set up or fix a CI/CD pipeline, GitHub Actions or GitLab CI workflow, deployment process, release automation, rollback strategy, or asks how to deploy to staging and production. Do not use for writing the tests themselves (testing-backend-services) or authoring Dockerfiles (containerizing-services).4---56<!--7Author: Simon-Pierre Boucher8Contact: contact@spboucher.ai9-->1011# Shipping with CI/CD1213## When to use / when NOT to use14- **Use for:** pipeline design/review, deploy strategy choice, environment promotion, release/rollback automation.15- **Do NOT use for:** test authoring (testing-backend-services), Dockerfile content (containerizing-services), or infra provisioning.1617## Core rules18191. **Main is always deployable.** Trunk-based development by default: short-lived branches, merge behind a green pipeline. A red main is the team's top priority.202. **Fail fast, in cost order.** Stage sequence: lint/typecheck → unit tests → build → integration tests → security scan → deploy. Cheap checks first so failures cost seconds, not minutes.213. **Build once, promote the artifact.** The exact image/binary tested in staging is byte-identical in production — tag by commit SHA.22   - ✅ `svc:3f2a91c` promoted staging → prod23   - ❌ Rebuilding "the same" code per environment (different deps, different artifact).244. **Pick the deploy strategy by risk, not fashion.** Rolling is the default; blue-green when you need instant rollback; canary (1–5% traffic, then ramp) for high-risk changes. Anything beyond rolling must justify its infra cost.255. **Rollback is automated, not heroic.** Health checks/SLO probes gate each deploy step; regression triggers automatic rollback to the previous artifact. If rollback requires a human running commands from memory, it isn't a rollback plan.266. **Migrations deploy before code and stay one version backward-compatible.** Old code must run against the new schema (expand → deploy → contract). Never couple a destructive migration to the deploy that needs it.277. **Secrets come from the platform** (environment/secret manager, OIDC cloud auth) — never committed in pipeline YAML, never echoed in logs.288. **Keep the pipeline under ~10 minutes** commit-to-verdict. Parallelize test shards, cache dependencies; a slow pipeline silently kills trunk-based flow.2930## Workflow31321. Map stages in cost order (rule 2); wire caching for dependency steps.332. Emit one artifact tagged with the commit SHA; push to the registry once.343. Define environments (staging auto-deploys on main; production gated by promotion of the same artifact).354. Add deploy gates: health-check verification after each batch, automatic rollback on failure (rule 5).365. Wire migrations as a separate pre-deploy step with a rehearsed rollback (rule 6).376. Validate: run a deliberately failing commit (lint error) and confirm the pipeline stops at stage 1; deploy a canary/rolling change and kill an instance mid-deploy — confirm zero failed requests and automatic recovery.3839## Edge cases & failure modes40- **Flaky tests** → quarantine tagged-flaky tests to a non-blocking stage the same day; a pipeline people retry until green is a pipeline nobody trusts.41- **Hotfix while main is red** → fix forward on main; the deployable-main rule makes dedicated hotfix branches unnecessary.42- **Long-running migration locks a hot table** → split into batched backfills; see db-skills/managing-database-migrations.43- **Rollback needed but migration was destructive** → this is a rule-6 violation; restore path is a backup drill, so keep contract phases a release behind.4445## References46Pipeline templates and gotchas: see [references/patterns.md](references/patterns.md).47