cxc-dev-devops

Dev-DevOps — Production Infrastructure & Delivery

Backend handoff rule: When a deploy/SRE gate needs app behavior, dev-backend implements the hook (health handler, readiness dependency check, trace/span/log fields, migration compatibility, shutdown hook). dev-devops defines the operational gate, rollout/rollback behavior, alert policy, and release proof. This skill owns deployment strategy, rollback proof, observability operations, health/readiness operational gates, SLOs, incident response, and infrastructure/runtime delivery.

Build reliable, secure, and automated infrastructure and delivery pipelines. This skill is a routing role that activates by change-surface: whenever the work primarily touches containers, CI/CD, deployment, cloud/runtime infrastructure, Kubernetes, IaC, release engineering, or SRE operations, use this skill and then load the relevant references.

C0/C1 work (small local patches): See dev §0.0 Work Classifier + §0.1 Patch Fast-Path before reading references.

dev is canonical: dev §0.2 Rule Classes, §3 Verification Gate, and §5 Safety Rules apply to all work governed by this skill.

Severity mapping: CRITICAL/HIGH ⇒ STRICT; MEDIUM ⇒ DEFAULT (aligned with dev §0.2).

Modular References

Read package-release.md for package publishing, registry auth, npm/PyPI trusted publishing, Bun-to-npm release decisions, and downstream package channels. Read cross-platform-release.md when a release claim depends on OS-local behavior that CI may not prove. Read homebrew.md for Formula/Cask distribution work. Read platform-engineering.md for broader DevOps capability refresh, DORA, provider routing, and platform guardrails. Read docker.md + ci-cd-deploy.md first for containerized deploy workflows. For K8s-specific work, add kubernetes.md. For SRE/on-call, add sre-foundations.md.

When release, registry-auth, provider-doc, service-status, image/platform version, or package-manager behavior depends on current external evidence, read the active search skill and follow its source-fetch and evidence-status rules instead of relying on stale memory or copied snippets.

§1 Container Builds

§1.1 Dockerfile Rules (STRICT)

For canonical Dockerfile templates, read references/docker.md §1.

§1.2 Image Security (STRICT)

CRITICAL/HIGH findings → block push. No exceptions. Read references/docker.md §4 for scan/SBOM/sign command examples, and ../dev-security/references/supply-chain-sbom.md for deeper SBOM/signing policy.

§1.3 Anti-Patterns

§2 Deploy Pipeline

§2.1 Pipeline Stages (DEFAULT)

[dev-testing §5]  lint → typecheck → test → contract → e2e
[dev-devops]      build-image → scan → push-registry → deploy-staging → smoke → promote → deploy-prod

§2.2 GHA Reusable Workflows (DEFAULT)

# .github/workflows/ci.yml (caller)
jobs:
  build:
    uses: org/templates/.github/workflows/build-test.yml@v2
    with:
      service: payments
    secrets: inherit

§2.3 Deploy Strategies (DEFAULT)

§2.4 Rollback Rules (STRICT)

• Every deployment must be rollback-capable within 5 minutes
• Digest-based promote only — mutable tags are banned
• DB migrations: forward-only + backward-compatible (expand-contract pattern)
• Post-rollback: automatic Slack/PagerDuty notification

§2.5 Secret Management (STRICT)

Rule (DEVOPS-AUTH-01): Prefer OIDC, workload identity federation, trusted publishing, or other short-lived credential flows before static long-lived tokens. When static tokens are unavoidable, scope narrowly, store in the managed secret system, and rotate on schedule or incident.

§2.6 GitOps (DEFAULT)

• Actions = CI, ArgoCD = CD — separation of concerns
• Actions updates deploy repo (image digest PR/commit) → ArgoCD reconciles
• Self-heal: ArgoCD auto-reverts drift
• Environment protection: GitHub Environments for prod approval gate

§2.7 Release Proof Contract (STRICT)

Rule (DEVOPS-RELEASE-PROOF-01): A release claim must name the artifact digest, workflow/builder identity, deploy target/environment, smoke-test evidence, and rollback evidence. Keep the proof at router level; detailed package, platform, and SLSA mechanics live in package-release.md, cross-platform-release.md, and platform-engineering.md.

§3 Kubernetes Basics

§3.1 Minimum Viable K8s (DEFAULT)

§3.2 Gateway API (v1.6+, verified 2026-07-02 — TCPRoute/UDPRoute GA in v1.6)

Gateway API is the successor for new routing while Ingress remains GA but feature-frozen. Role separation: platform team owns GatewayClass + Gateway, app team owns HTTPRoute.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: payments-route
spec:
  parentRefs:
    - name: shared-gateway
  hostnames: ["payments.example.com"]
  rules:
    - matches:
        - path: { type: PathPrefix, value: /api }
      backendRefs:
        - name: payments-svc
          port: 8080

§3.3 Scaling (DEFAULT)

§3.4 Anti-Patterns

§4 Infrastructure as Code

§4.1 OpenTofu/Terraform Rules (DEFAULT)

§4.2 Tool Selection (HEURISTIC)

§4.3 Anti-Patterns

§5 SRE Foundations

§5.1 SLO/SLI (DEFAULT)

SLIs measure user experience, not infrastructure metrics. "CPU is fine ≠ users are fine."

Error budget = 1 − SLO (99.9% → 0.1% budget).

DORA 2025 (verified 2026-07-02): AI acts as an amplifier — returns depend on the underlying sociotechnical system. For AI-agent-heavy delivery invest in golden paths, guardrails, observability, provenance, and review gates.

§5.2 Error Budget Policy (DEFAULT)

Single incident consuming >20% → mandatory postmortem. Two consecutive window misses → architecture review.

§5.3 Incident Response (DEFAULT)

1. Detect → Triage (S1/S2/S3) → Stabilize → Fix → Postmortem
2. Roles: IC, Primary Responder, Comms Lead, Scribe
3. Mitigation first, diagnosis second during active incidents
4. All S1/S2 → mandatory blameless postmortem within 5 business days
5. Status updates: S1 every 15min, S2 every 30min

§5.4 Runbook Template (HEURISTIC)

## [Service] — [Symptom]
### Diagnosis
1. Logs: `kubectl logs -l app=<name> --tail=100`
2. Metrics: Grafana → [dashboard URL]
3. Dependencies: `curl -s http://<dep>/health | jq .`
### Emergency Mitigation
1. Rollback: `argocd app rollback <app>`
2. Traffic block: ...
### Root Fix
1. ...
### Escalation
- Owner: @team-sre
- PagerDuty: [policy]

§5.5 Anti-Patterns

§6 Cross-References

dev-devops owns: container builds, deploy pipelines, K8s manifests, IaC modules, SRE/incident response, edge infra, ML infra. DevOps owns operational scan execution and release gates; dev-security owns security policy, severity thresholds, and required evidence. dev-backend owns: application-layer observability code, API design, health check implementation. Overlap: observability alerting rules (dev-devops §5) ↔ observability code instrumentation (dev-backend observability.md). Cross-ref both.

Pre-flight Checklist

Before submitting infrastructure changes:

• Dockerfile is multi-stage with distroless/slim final image and non-root user
• Image scanned (Trivy/Scout) with CRITICAL/HIGH gate — no unresolved findings
• SBOM generated and attestation signed (Cosign) for production images
• Deploy pipeline uses digest-based promotion, never mutable tags
• K8s manifests have resource requests/limits, probes, PDB, and use Gateway API (not Ingress)
• IaC uses remote state, pinned versions, and modular decomposition
• Secrets are managed through Vault/AWS SM/GHA Secrets — no .env commits, no ARG secrets
• SLO/SLI defined with error budget policy and burn-rate alerting
• Rollback plan documented and tested — <5min rollback capability confirmed
• Runbook exists for critical failure scenarios