Back to Details

deployment-procedures

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Deployment Procedures

部署流程

Deployment principles and decision-making for safe production releases. Learn to THINK, not memorize scripts.
面向安全生产发布的部署原则与决策制定。 学会思考，而非死记硬背脚本。

⚠️ How to Use This Skill

⚠️ 如何使用本技能

This skill teaches deployment principles, not bash scripts to copy.
  • Every deployment is unique
  • Understand the WHY behind each step
  • Adapt procedures to your platform
本技能传授部署原则，而非可供复制的bash脚本。
  • 每一次部署都是独特的
  • 理解每一步背后的原因
  • 根据你的平台调整流程

1. Platform Selection

1. 平台选择

Decision Tree

决策树

What are you deploying?
│
├── Static site / JAMstack
│   └── Vercel, Netlify, Cloudflare Pages
│
├── Simple web app
│   ├── Managed → Railway, Render, Fly.io
│   └── Control → VPS + PM2/Docker
│
├── Microservices
│   └── Container orchestration
│
└── Serverless
    └── Edge functions, Lambda
你要部署什么？
│
├── 静态网站 / JAMstack
│   └── Vercel, Netlify, Cloudflare Pages
│
├── 简单Web应用
│   ├── 托管式 → Railway, Render, Fly.io
│   └── 自主控制 → VPS + PM2/Docker
│
├── 微服务
│   └── 容器编排
│
└── 无服务器
    └── Edge functions, Lambda

Each Platform Has Different Procedures

不同平台对应不同流程

PlatformDeployment Method
Vercel/NetlifyGit push, auto-deploy
Railway/RenderGit push or CLI
VPS + PM2SSH + manual steps
DockerImage push + orchestration
Kuberneteskubectl apply
平台部署方式
Vercel/NetlifyGit推送，自动部署
Railway/RenderGit推送或CLI
VPS + PM2SSH + 手动步骤
Docker镜像推送 + 编排
Kuberneteskubectl apply

2. Pre-Deployment Principles

2. 部署前原则

The 4 Verification Categories

四类验证范畴

CategoryWhat to Check
Code QualityTests passing, linting clean, reviewed
BuildProduction build works, no warnings
EnvironmentEnv vars set, secrets current
SafetyBackup done, rollback plan ready
范畴检查内容
代码质量测试通过、代码规范检查合格、已完成评审
构建生产构建正常、无警告
环境环境变量已配置、密钥为最新状态
安全已完成备份、回滚计划就绪

Pre-Deployment Checklist

部署前检查清单

  • All tests passing
  • Code reviewed and approved
  • Production build successful
  • Environment variables verified
  • Database migrations ready (if any)
  • Rollback plan documented
  • Team notified
  • Monitoring ready
  • 所有测试通过
  • 代码已评审并获批准
  • 生产构建成功
  • 环境变量已验证
  • 数据库迁移已准备就绪（如有）
  • 回滚计划已文档化
  • 已通知团队
  • 监控已就绪

3. Deployment Workflow Principles

3. 部署工作流原则

The 5-Phase Process

五阶段流程

1. PREPARE
   └── Verify code, build, env vars

2. BACKUP
   └── Save current state before changing

3. DEPLOY
   └── Execute with monitoring open

4. VERIFY
   └── Health check, logs, key flows

5. CONFIRM or ROLLBACK
   └── All good? Confirm. Issues? Rollback.
1. 准备阶段
   └── 验证代码、构建结果、环境变量

2. 备份阶段
   └── 在变更前保存当前状态

3. 部署阶段
   └── 执行部署并保持监控开启

4. 验证阶段
   └── 健康检查、日志查看、关键流程测试

5. 确认或回滚
   └── 一切正常？确认部署。出现问题？执行回滚。

Phase Principles

各阶段原则

PhasePrinciple
PrepareNever deploy untested code
BackupCan't rollback without backup
DeployWatch it happen, don't walk away
VerifyTrust but verify
ConfirmHave rollback trigger ready
阶段原则
准备绝不部署未测试的代码
备份无备份则无法回滚
部署全程监控，不要走开
验证保持信任但也要验证
确认随时准备触发回滚

4. Post-Deployment Verification

4. 部署后验证

What to Verify

验证内容

CheckWhy
Health endpointService is running
Error logsNo new errors
Key user flowsCritical features work
PerformanceResponse times acceptable
检查项原因
健康检查端点确认服务正在运行
错误日志确认无新增错误
关键用户流程确认核心功能正常工作
性能确认响应时间在可接受范围内

Verification Window

验证时间窗口

  • First 5 minutes: Active monitoring
  • 15 minutes: Confirm stable
  • 1 hour: Final verification
  • Next day: Review metrics
  • 前5分钟：主动监控
  • 15分钟后：确认服务稳定
  • 1小时后：最终验证
  • 次日：回顾指标数据

5. Rollback Principles

5. 回滚原则

When to Rollback

何时回滚

SymptomAction
Service downRollback immediately
Critical errorsRollback
Performance >50% degradedConsider rollback
Minor issuesFix forward if quick
症状操作
服务宕机立即回滚
严重错误执行回滚
性能下降超过50%考虑回滚
轻微问题若可快速修复则直接修复

Rollback Strategy by Platform

各平台回滚方式

PlatformRollback Method
Vercel/NetlifyRedeploy previous commit
Railway/RenderRollback in dashboard
VPS + PM2Restore backup, restart
DockerPrevious image tag
K8skubectl rollout undo
平台回滚方法
Vercel/Netlify重新部署之前的提交版本
Railway/Render在控制台中执行回滚
VPS + PM2恢复备份并重启服务
Docker使用之前的镜像标签
K8skubectl rollout undo

Rollback Principles

回滚原则

  1. Speed over perfection: Rollback first, debug later
  2. Don't compound errors: One rollback, not multiple changes
  3. Communicate: Tell team what happened
  4. Post-mortem: Understand why after stable
  1. 速度优先于完美：先回滚，再调试
  2. 不要叠加错误：只执行一次回滚，不要同时进行多项变更
  3. 及时沟通：告知团队发生的情况
  4. 事后复盘：服务稳定后分析原因

6. Zero-Downtime Deployment

6. 零停机部署

Strategies

策略类型

StrategyHow It Works
RollingReplace instances one by one
Blue-GreenSwitch traffic between environments
CanaryGradual traffic shift
策略工作原理
滚动更新逐个替换实例
蓝绿部署在两个环境之间切换流量
金丝雀发布逐步转移流量

Selection Principles

策略选择原则

ScenarioStrategy
Standard releaseRolling
High-risk changeBlue-green (easy rollback)
Need validationCanary (test with real traffic)
场景策略
标准发布滚动更新
高风险变更蓝绿部署（回滚简单）
需要验证效果金丝雀发布（用真实流量测试）

7. Emergency Procedures

7. 应急流程

Service Down Priority

服务宕机处理优先级

  1. Assess: What's the symptom?
  2. Quick fix: Restart if unclear
  3. Rollback: If restart doesn't help
  4. Investigate: After stable
  1. 评估：症状是什么？
  2. 快速修复：若原因不明，先尝试重启
  3. 回滚：若重启无效则执行回滚
  4. 调查：服务稳定后再调查原因

Investigation Order

调查顺序

CheckCommon Issues
LogsErrors, exceptions
ResourcesDisk full, memory
NetworkDNS, firewall
DependenciesDatabase, APIs
检查项常见问题
日志错误、异常信息
资源磁盘已满、内存不足
网络DNS问题、防火墙限制
依赖项数据库、API故障

8. Anti-Patterns

8. 反模式

❌ Don't✅ Do
Deploy on FridayDeploy early in week
Rush deploymentFollow the process
Skip stagingAlways test first
Deploy without backupBackup before deploy
Walk away after deployMonitor for 15+ min
Multiple changes at onceOne change at a time
❌ 不要做✅ 应该做
周五部署周内早间部署
仓促部署遵循流程执行
跳过预发布环境测试始终先测试
不备份就部署部署前先备份
部署后立刻离开监控15分钟以上
同时进行多项变更一次只做一项变更

9. Decision Checklist

9. 决策检查清单

Before deploying:
  • Platform-appropriate procedure?
  • Backup strategy ready?
  • Rollback plan documented?
  • Monitoring configured?
  • Team notified?
  • Time to monitor after?
部署前确认：
  • 流程是否适配平台？
  • 备份策略是否就绪？
  • 回滚计划是否已文档化？
  • 监控是否已配置？
  • 是否已通知团队？
  • 是否有时间进行部署后监控？

10. Best Practices

10. 最佳实践

  1. Small, frequent deploys over big releases
  2. Feature flags for risky changes
  3. Automate repetitive steps
  4. Document every deployment
  5. Review what went wrong after issues
  6. Test rollback before you need it
Remember: Every deployment is a risk. Minimize risk through preparation, not speed.
  1. 优先选择小而频繁的部署，而非大规模发布
  2. 对高风险变更使用功能开关
  3. 自动化重复步骤
  4. 为每一次部署建立文档
  5. 出现问题后回顾分析原因
  6. 在需要之前测试回滚流程
记住： 每一次部署都存在风险。通过充分准备而非追求速度来降低风险。