environment-deployment-strategy

环境部署策略

这是一个参考模式。 从这种方法中汲取经验，并根据你的情况进行调整——不要照搬。

问题：需要安全的部署实践，既能防止意外部署到生产环境，又能支持快速迭代开发。

解决方案：采用三层环境策略，并设置部署限制。

---

模式

三个环境：

1. 本地（local）

   • 在开发者的计算机上运行
   • 使用来自 dev 环境的云资源
   • 无法部署（没有云资源）
   • 快速迭代，无需等待部署

2. 开发（dev）

   • 部署到云端
   • 与生产环境的架构保持一致
   • 可通过以下方式部署：本地脚本或 GitHub Actions（合并到 dev 分支时）
   • 用于测试和验证

3. 生产（prod）

   • 部署到云端
   • 面向客户的线上环境
   • 只能通过以下方式部署：GitHub Actions（合并到 main 分支时）
   • 绝不从本地计算机部署

---

为什么采用这种模式？

优点：

• 安全性：保护生产环境，避免从本地意外部署
• 速度：本地开发使用云端开发资源（无需本地基础设施）
• 一致性：开发环境与生产环境保持一致，提前发现问题
• 审计跟踪：所有生产部署都会记录在 GitHub Actions 日志中
• 回滚：利用 Git 历史记录轻松回滚

可防止：

• 从开发者计算机意外部署到生产环境
• 未经测试的代码进入生产环境
• 环境之间的配置漂移
• “在我的机器上能运行”问题

---

实现

环境配置：

# .env (local - not committed)
ENVIRONMENT=local
AWS_REGION=eu-central-1
# Uses dev resources
API_ENDPOINT=https://api-dev.example.com

# .env.dev (committed template)
ENVIRONMENT=dev
AWS_REGION=eu-central-1
API_ENDPOINT=https://api-dev.example.com

# .env.prod (committed template, secrets from SSM)
ENVIRONMENT=prod
AWS_REGION=eu-central-1
API_ENDPOINT=https://api.example.com

部署脚本：

// package.json
{
  "scripts": {
    "deploy:dev": "cdk deploy --all --context environment=dev",
    "deploy:prod": "echo 'ERROR: Production can only be deployed via GitHub Actions' && exit 1"
  }
}

GitHub Actions 工作流：

# .github/workflows/deploy.yml
name: Deploy

on:
  pull_request:
    types: [closed]
    branches: [dev, main]

jobs:
  deploy-dev:
    if: github.base_ref == 'dev' && github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to Dev
        run: npm run deploy:dev

  deploy-prod:
    if: github.base_ref == 'main' && github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to Production
        run: cdk deploy --all --context environment=prod

---

部署流程

开发周期：

1. Developer works locally (uses dev resources)
2. Commits to feature branch
3. Opens PR to dev branch
4. PR merged → GitHub Actions deploys to dev
5. Test in dev environment
6. Open PR from dev to main
7. PR merged → GitHub Actions deploys to prod

本地开发：

# Developer runs frontend locally
npm run dev

# Frontend connects to dev API
# No infrastructure deployment needed
# Fast iteration

开发环境部署（两种方式）：

# Option 1: Local deployment (for quick testing)
npm run deploy:dev

# Option 2: GitHub Actions (on PR merge to dev)
# Automatic, tracked, consistent

生产环境部署（仅一种方式）：

# Only via GitHub Actions (on PR merge to main)
# Attempting local deployment fails with error message

---

CORS：本地共用开发后端

由于本地开发会调用已部署的开发 API，开发环境的 CORS 必须允许这两个来源：

# .env.dev (used by dev Lambda)
CORS_ALLOWED_ORIGINS=http://localhost:3010,https://dev.project.example.com

# .env.prod (only the production domain)
CORS_ALLOWED_ORIGINS=https://project.example.com

规则：为任何开发后端（API Gateway、Lambda）配置 CORS 时，始终将 http://localhost:<port> 与已部署的开发前端域名一并加入。否则，本地开发会被 CORS 拦截，而已部署的开发前端则可以正常运行。

---

资源隔离

各环境使用独立资源：

// All resources include environment identifier
const bucket = new s3.Bucket(this, 'Bucket', {
  bucketName: `${PROJECT_ID}-data-${environment}` // dev or prod
});

const table = new dynamodb.Table(this, 'Table', {
  tableName: `${PROJECT_ID}-users-${environment}` // dev or prod
});

原因：防止开发和生产环境共用资源，避免数据损坏和冲突。

---

AWS CodePipeline 集成

替代方案：使用 AWS CodePipeline 代替 GitHub Actions

// Separate pipelines per environment
const devPipeline = new codepipeline.Pipeline(this, 'DevPipeline', {
  pipelineName: `${PROJECT_ID}-pipeline-dev`
});

const prodPipeline = new codepipeline.Pipeline(this, 'ProdPipeline', {
  pipelineName: `${PROJECT_ID}-pipeline-prod`
});

GitHub Actions 触发器：

- name: Trigger Dev Pipeline
  run: aws codepipeline start-pipeline-execution --name ${PROJECT_ID}-pipeline-dev

- name: Trigger Prod Pipeline
  run: aws codepipeline start-pipeline-execution --name ${PROJECT_ID}-pipeline-prod

优点：

• 在 AWS CloudWatch 中查看构建日志
• 使用基于 IAM 的权限（无需 GitHub 密钥）
• 与 AWS 服务集成

---

变体

双环境（适合较简单的项目）：

• dev - 开发和测试
• prod - 仅用于生产

四环境（适合企业项目）：

• local - 开发者计算机
• dev - 开发
• staging - 预生产测试
• prod - 生产

---

相关模式

• 资源命名 - 如何按环境为资源命名
• 环境验证 - 尽早验证环境配置
• 静态前端托管 - 部署流水线示例

---

渐进式改进

如果开发者纠正了本技能本应避免的行为，请建议对本技能进行具体修改，以防止今后再次出现同样的问题。