Token导航 LogoToken导航TokenDH.com
开发敏感数据github未标认证来源可访问许可证需确认审计通过

phase-9-deployment第 9 阶段部署

Agent Skill

用于辅助云资源、部署、容器、基础设施和运维自动化任务。它适合让 Agent 检查配置、整理部署步骤、分析资源状态、生成排障思路或辅助云服务接入。使用时需要明确目标环境、账号权限、区域和资源组,区分本地测试与生产操作;涉及删除资源、重启服务、修改网络或权限配置时,应先确认影响范围。

总安装

792

周安装

33

GitHub Stars

520

下载量

264
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:phase-9-deployment(第 9 阶段部署)
来源仓库:https://github.com/popup-studio-ai/bkit-claude-code
仓库路径:skills/phase-9-deployment
安装命令:
npx skills add https://github.com/popup-studio-ai/bkit-claude-code --skill phase-9-deployment
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/popup-studio-ai/bkit-claude-code --skill phase-9-deployment

简介

用于辅助云资源、部署和容器运维自动化任务。适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

  • 适合检查配置、整理部署步骤或分析资源状态。
  • 通过 npx skills add 命令从 GitHub 仓库安装使用。
  • 涉及删除资源或修改网络时应先确认影响范围。
  • phase-9-deployment 属于开发类 Skill,可作为该场景下的辅助能力补充。

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

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

36.08%
按下载量换算95

Claude

32.95%
按下载量换算87

Cursor

18.44%
按下载量换算49

Gemini CLI

9.72%
按下载量换算26

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

敏感数据

该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills