agentleFS
ww-w-aiww-w-ai/bkit-claude-code/skills/phase-9-deployment/SKILL.md

phase-9-deployment

Skill605 starsChanged 3 months agoApache-2.0View on GitHub

Deploy to production — CI/CD pipelines, environment config, deployment strategies. Triggers: deployment, CI/CD, production, Vercel

  • Reads credentials
  • Installs packages

3 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Build: Create production build

    line 36

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Phase 9: Deployment

Production deployment

Purpose

Deliver the completed application to users.

What to Do in This Phase

  1. Prepare Deployment Environment: Infrastructure setup
  2. Build: Create production build
  3. Execute Deployment: Actual deployment
  4. Verification: Post-deployment operation check

Deliverables

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

PDCA Application

  • Plan: Establish deployment plan
  • Design: Design deployment configuration
  • Do: Execute deployment
  • Check: Verify deployment
  • Act: Problem resolution and completion report

Level-wise Application

LevelDeployment Method
StarterStatic hosting (Netlify, GitHub Pages)
DynamicVercel, Railway, etc.
EnterpriseKubernetes, AWS ECS, etc.

Starter Deployment (Static Hosting)

# GitHub Pages
npm run build
# Deploy dist/ folder to gh-pages branch

# Netlify
# Configure netlify.toml then connect Git

Dynamic Deployment (Vercel)

# Vercel CLI
npm i -g vercel
vercel

# Or auto-deploy via Git connection

Enterprise Deployment (Kubernetes)

# 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 Management

Environment Configuration Overview

┌─────────────────────────────────────────────────────────────┐
│                     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 Classification

EnvironmentPurposeDataVariable Source
DevelopmentLocal developmentTest data.env.local
StagingPre-deployment verificationTest dataCI/CD Secrets
ProductionLive serviceReal dataCI/CD Secrets + Vault

CI/CD Environment Variable Configuration

GitHub Actions

# .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

GitHub Secrets Configuration Guide

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)

Vercel Environment Variable Configuration

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)

Secrets Management Strategy

Level-wise Secrets Management

LevelSecrets Management MethodTools
StarterCI/CD platform SecretsGitHub Secrets, Vercel
DynamicCI/CD + environment separationGitHub Environments
EnterpriseDedicated Secrets ManagerVault, AWS Secrets Manager

Starter/Dynamic: CI/CD Secrets

# Usage in GitHub Actions
- name: Deploy
  env:
    DB_PASSWORD: ${{ secrets.DB_PASSWORD }}

Enterprise: HashiCorp Vault

# 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

Enterprise: AWS Secrets Manager

// 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: "...", ... }

Environment-specific Build Configuration

Next.js Environment Configuration

// 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;

Environment-specific API Endpoints

// 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];

Environment Variable Validation (Pre-deployment)

Required Variable Check Script

#!/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');

Validation in CI/CD

# 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 }}

Environment Variable Management Checklist

Pre-deployment

  • Secrets Registration
    • DATABASE_URL (per environment)
    • AUTH_SECRET (per environment)
    • External API keys (per environment)
  • Environment Separation
    • Development / Staging / Production distinction
    • Per-environment database separation
    • Per-environment external service key separation (test/live)
  • Validation
    • Run required variable check script
    • Build test

Post-deployment

  • Operation Check
    • Verify environment variables are injected correctly
    • External service integration test
  • Security Check
    • Verify no sensitive info in logs
    • Verify no server-only variables exposed to client

Deployment Checklist

Preparation

  • Environment variable configuration (see checklist above)
  • Domain connection
  • SSL certificate

Deployment

  • Build successful
  • Deployment complete
  • Health check passed

Verification

  • Major feature operation check
  • Error log review
  • Performance monitoring

Rollback Plan

If problems occur:
1. Immediately rollback to previous version
2. Analyze root cause
3. Fix and redeploy

Template

See templates/pipeline/phase-9-deployment.template.md

After Completion

Project complete! Start new feature development cycle from Phase 1 as needed

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.