Deploy Skill
Deploy code to target environment with automated CI/CD pipeline generation. Strategy adapts based on project level (Starter/Dynamic/Enterprise).
Usage
bash/pdca deploy {feature} # Deploy to default env (dev) /pdca deploy {feature} --env dev # Deploy to DEV /pdca deploy {feature} --env staging # Deploy to STAGING (requires DEV 90%+) /pdca deploy {feature} --env prod # Deploy to PROD (requires STAGING 95%+ & Human Approval) /pdca deploy status # Show deploy state machine status
Level-Based Strategy
| Level | Strategy | Environments | Tools |
|---|---|---|---|
| Starter | Guide only | dev | GitHub Pages, Netlify, Vercel |
| Dynamic | Docker + GHA | dev, staging | Docker Compose, GitHub Actions |
| Enterprise | 6-Layer CI/CD | dev, staging, prod | Terraform, EKS, ArgoCD, Canary |
Deploy Flow
/pdca deploy feature --env dev │ ▼ ① Level Detection (Starter/Dynamic/Enterprise) │ ▼ ② Generate CI/CD Files (if not exist) ├── .github/workflows/deploy.yml ├── Dockerfile (Dynamic/Enterprise) ├── docker-compose.yml (DEV) ├── k8s/ manifests (Enterprise) └── terraform/ (Enterprise) │ ▼ ③ Deploy State Machine Transition init → dev → verify(90%) → staging → verify(95%) → approval → prod(canary) → complete │ ▼ ④ Return to PDCA Check phase
Environment Promotion Gates
| Gate | Condition | Action |
|---|---|---|
| DEV → STAGING | Match Rate ≥ 90% | Auto-promote |
| STAGING → PROD | Match Rate ≥ 95% + Human Approval | Require /pdca deploy --env prod |
| PROD Canary | Error rate < threshold | Auto-rollout 10% → 25% → 50% → 100% |
Generated Files
Starter
- Deployment guide document only
Dynamic
.github/workflows/deploy.yml— Docker build + push + deployDockerfile— Multi-stage builddocker-compose.yml— DEV environment.env.example— Environment variables template
Enterprise (additional)
infra/terraform/— AWS infrastructureinfra/k8s/— Kubernetes manifestsinfra/argocd/— ArgoCD Application + Helm- Security scan steps in CI/CD
Rollback
bash/pdca deploy rollback {feature} # Rollback current deploy /pdca deploy rollback {feature} --env prod # Rollback specific environment
Rollback triggers:
- Manual:
/pdca deploy rollbackcommand - Auto: Error rate spike detected by ops-metrics (> 5% threshold)
- Canary fail: Argo Rollouts auto-rollback on metrics failure
- Self-healing escalation: When
self-healingagent exhausts its 5-iteration auto-fix budget without restoring SLO, it triggers/pdca deploy rollbackas final remediation (see Self-Healing Integration below).
Rollback resets deploy state machine to idle and restores previous version.
Self-Healing Integration (v2.1.13)
The self-healing agent (linked-from-skills: deploy) closes the deploy ⇄ recovery loop:
| Stage | Trigger | Action |
|---|---|---|
| Detect | Sentry/Slack error pattern matches deploy window | self-healing agent activated via 8-lang triggers ("자동 수정", "auto fix", etc.) |
| Diagnose | 4-Layer Living Context loaded (Scenarios + Invariants + Impact + Incidents) | Identify deploy-introduced regression |
| Auto-fix | Spawn code-analyzer + gap-detector via Task tool | Up to 5 iteration cycles with scenario runner verification |
| Verify | Re-run feature scenarios | Pass → auto PR; Fail → escalate |
| Escalate | Iteration budget exhausted or critical invariant violated | Trigger /pdca deploy rollback + alert human on-call |
Invocation paths:
- Implicit: Sentry webhook → self-healing agent (via plugin trigger registry)
- Explicit:
/pdca deploy rollbackfirst checks for active self-healing session and aborts to wait for it; user can force-bypass with--force-rollback
The self-healing → deploy contract is mediated by lib/audit/audit-logger.js ACTION_TYPES (rollback_executed, agent_completed, gate_failed) so all transitions remain audit-trail compliant.
Hook Events
| Event | When | Hook |
|---|---|---|
deploy-start | Deploy initiated | Pre-validation |
deploy-complete | Deploy successful | Post-notification |
deploy-failed | Deploy failed | Error handling + rollback suggestion |
