skills/phase-9-deployment/SKILL.md
--- name: phase-9-deployment classification: capability classification-reason: Pattern guidance may overlap with model's built-in knowledge as it improves deprecation-risk: medium effort: medium user-invocable: false description: | Deploy to production — CI/CD pipelines, environment config, deployment strategies. Triggers: deployment, CI/CD, production, Vercel, 배포, 프로덕션. imports: - ${PLUGIN_ROOT}/templates/pipeline/phase-9-deployment.template.md agent: bkit:infra-architect allowed-tools:
npx skillsauth add popup-studio-ai/bkit-claude-code skills/phase-9-deploymentInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Production deployment
Deliver the completed application to users.
docs/02-design/
└── deployment-spec.md # Deployment specification
docs/04-report/
└── deployment-report.md # Deployment report
(Infrastructure config files)
├── vercel.json # Vercel configuration
├── Dockerfile # Docker configuration
└── k8s/ # Kubernetes configuration
| Level | Deployment Method | |-------|-------------------| | Starter | Static hosting (Netlify, GitHub Pages) | | Dynamic | Vercel, Railway, etc. | | Enterprise | Kubernetes, AWS ECS, etc. |
# GitHub Pages
npm run build
# Deploy dist/ folder to gh-pages branch
# Netlify
# Configure netlify.toml then connect Git
# Vercel CLI
npm i -g vercel
vercel
# Or auto-deploy via Git connection
# k8s/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
template:
spec:
containers:
- name: app
image: my-app:latest
┌─────────────────────────────────────────────────────────────┐
│ Environment Variable Flow │
├─────────────────────────────────────────────────────────────┤
│ │
│ Development │
│ └── .env.local → Developer local machine │
│ │
│ Staging │
│ └── CI/CD Secrets → Preview/Staging environment │
│ │
│ Production │
│ └── CI/CD Secrets → Production environment │
│ └── Vault/Secrets Manager (Enterprise) │
│ │
└─────────────────────────────────────────────────────────────┘
| Environment | Purpose | Data | Variable Source |
|-------------|---------|------|-----------------|
| Development | Local development | Test data | .env.local |
| Staging | Pre-deployment verification | Test data | CI/CD Secrets |
| Production | Live service | Real data | CI/CD Secrets + Vault |
# .github/workflows/deploy.yml
name: Deploy
on:
push:
branches: [main, staging]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set environment
run: |
if [ "${{ github.ref }}" == "refs/heads/main" ]; then
echo "DEPLOY_ENV=production" >> $GITHUB_ENV
else
echo "DEPLOY_ENV=staging" >> $GITHUB_ENV
fi
- name: Build
env:
# General environment variables (can be exposed)
NEXT_PUBLIC_APP_URL: ${{ vars.APP_URL }}
NEXT_PUBLIC_API_URL: ${{ vars.API_URL }}
# Secrets (sensitive info)
DATABASE_URL: ${{ secrets.DATABASE_URL }}
AUTH_SECRET: ${{ secrets.AUTH_SECRET }}
API_STRIPE_SECRET: ${{ secrets.API_STRIPE_SECRET }}
run: npm run build
- name: Deploy to Vercel
env:
VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}
run: |
npx vercel --prod --token=$VERCEL_TOKEN
Repository Settings → Secrets and variables → Actions
1. Repository secrets (sensitive info)
├── DATABASE_URL
├── AUTH_SECRET
├── API_STRIPE_SECRET
└── VERCEL_TOKEN
2. Repository variables (general settings)
├── APP_URL
├── API_URL
└── NODE_ENV
3. Environment-specific secrets
├── production/
│ ├── DATABASE_URL (production DB)
│ └── API_STRIPE_SECRET (live key)
└── staging/
├── DATABASE_URL (staging DB)
└── API_STRIPE_SECRET (test key)
Project Settings → Environment Variables
┌─────────────────┬─────────────┬─────────────┬─────────────┐
│ Variable Name │ Development │ Preview │ Production │
├─────────────────┼─────────────┼─────────────┼─────────────┤
│ DATABASE_URL │ dev-db │ staging-db │ prod-db │
│ AUTH_SECRET │ dev-secret │ stg-secret │ prod-secret │
│ API_STRIPE_* │ test key │ test key │ live key │
└─────────────────┴─────────────┴─────────────┴─────────────┘
Configuration steps:
1. Project Settings → Environment Variables
2. Add New Variable
3. Select environment (Development / Preview / Production)
4. Check Sensitive (if sensitive info)
| Level | Secrets Management Method | Tools | |-------|--------------------------|-------| | Starter | CI/CD platform Secrets | GitHub Secrets, Vercel | | Dynamic | CI/CD + environment separation | GitHub Environments | | Enterprise | Dedicated Secrets Manager | Vault, AWS Secrets Manager |
# Usage in GitHub Actions
- name: Deploy
env:
DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
# Fetch Secrets from Vault
- name: Import Secrets from Vault
uses: hashicorp/vault-action@v2
with:
url: https://vault.company.com
token: ${{ secrets.VAULT_TOKEN }}
secrets: |
secret/data/myapp/production db_password | DB_PASSWORD ;
secret/data/myapp/production api_key | API_KEY
// lib/secrets.ts
import { SecretsManagerClient, GetSecretValueCommand } from "@aws-sdk/client-secrets-manager";
const client = new SecretsManagerClient({ region: "ap-northeast-2" });
export async function getSecret(secretName: string): Promise<Record<string, string>> {
const command = new GetSecretValueCommand({ SecretId: secretName });
const response = await client.send(command);
if (response.SecretString) {
return JSON.parse(response.SecretString);
}
throw new Error(`Secret ${secretName} not found`);
}
// Usage
const dbSecrets = await getSecret("myapp/production/database");
// { host: "...", password: "...", ... }
// next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
// Environment-specific settings
env: {
NEXT_PUBLIC_ENV: process.env.NODE_ENV,
},
// Environment-specific redirects
async redirects() {
if (process.env.NODE_ENV === 'production') {
return [
{ source: '/debug', destination: '/', permanent: false },
];
}
return [];
},
};
module.exports = nextConfig;
// lib/config.ts
const config = {
development: {
apiUrl: 'http://localhost:3001',
debug: true,
},
staging: {
apiUrl: 'https://api-staging.myapp.com',
debug: true,
},
production: {
apiUrl: 'https://api.myapp.com',
debug: false,
},
} as const;
type Environment = keyof typeof config;
const env = (process.env.NODE_ENV || 'development') as Environment;
export const appConfig = config[env];
#!/usr/bin/env node
// scripts/check-env.js
const REQUIRED_VARS = [
'DATABASE_URL',
'AUTH_SECRET',
'NEXT_PUBLIC_APP_URL'
];
const missing = REQUIRED_VARS.filter(v => !process.env[v]);
if (missing.length > 0) {
console.error('❌ Missing required environment variables:');
missing.forEach(v => console.error(` - ${v}`));
process.exit(1);
}
console.log('✅ All required environment variables are set');
# GitHub Actions
- name: Validate Environment
run: node scripts/check-env.js
env:
DATABASE_URL: ${{ secrets.DATABASE_URL }}
AUTH_SECRET: ${{ secrets.AUTH_SECRET }}
NEXT_PUBLIC_APP_URL: ${{ vars.APP_URL }}
[ ] Secrets Registration
[ ] Environment Separation
[ ] Validation
[ ] Operation Check
[ ] Security Check
If problems occur:
1. Immediately rollback to previous version
2. Analyze root cause
3. Fix and redeploy
See templates/pipeline/phase-9-deployment.template.md
Project complete! Start new feature development cycle from Phase 1 as needed
testing
Sprint Management — generic sprint capability for ANY bkit user. 16 sub-actions: init, start, status, watch, phase, iterate, qa, report, archive, list, feature, pause, resume, fork, help, master-plan. Triggers: sprint, sprint start, sprint init, sprint status, sprint list, 스프린트, 스프린트 시작, 스프린트 상태, スプリント, スプリント開始, スプリント状態, 冲刺, 冲刺开始, 冲刺状态, sprint, iniciar sprint, estado sprint, sprint, demarrer sprint, statut sprint, Sprint, Sprint starten, Sprint Status, sprint, avviare sprint, stato sprint, master plan, multi-sprint plan, sprint master plan, 마스터 플랜, 멀티 스프린트 계획, 스프린트 마스터 플랜, マスタープラン, マルチスプリント計画, スプリントマスタープラン, 主计划, 多冲刺计划, 冲刺主计划, plan maestro, plan multi-sprint, plan maestro sprint, plan maître, plan multi-sprint, plan maître sprint, Masterplan, Multi-Sprint-Plan, Sprint-Masterplan, piano principale, piano multi-sprint, piano principale sprint.
tools
CC CLI version upgrade impact analysis — research changes, analyze bkit impact, generate report. Triggers: cc-version-analysis, CC upgrade, version analysis, CC 버전 분석, 버전 영향.
testing
Manage PDCA checkpoints and rollback — create, list, restore for safe recovery. Rollback events are recorded via lib/audit/audit-logger ACTION_TYPES.rollback_executed. For sprint-level recovery, individual feature rollbacks may be triggered from within sprint phases (sprint itself is forward-only — terminal state is `archived`, not rolled back; v2.1.13). Triggers: rollback, checkpoint, restore, undo, 롤백, 체크포인트, 복원.
testing
QA Phase execution — L1-L5 test planning, generation, execution, and reporting for a single feature. For sprint-level QA (7-Layer dataFlowIntegrity / S1 gate across multiple features) use /sprint qa <sprintId> which delegates to sprint-qa-flow agent (v2.1.13). Triggers: qa phase, QA test, qa run, QA 실행, QAフェーズ, QA阶段, fase QA, phase QA, QA-Phase, fase QA.