环境提升流水线设计
核心问题:代码从开发到生产需要经过哪些关口?怎样设计一个既安全又快速的 dev → staging → prod 晋级流程?
环境提升全流程
flowchart LR
DEV["开发环境\ndev"] -->|自动部署\n所有推送| STG["测试环境\nstaging"]
STG -->|集成测试通过| UAT["预生产\nuat/canary"]
UAT -->|人工审批\n+ 金丝雀监控| PRD["生产环境\nproduction"]
style DEV fill:#e3f2fd
style STG fill:#fff3e0
style UAT fill:#fce4ec
style PRD fill:#c8e6c9
镜像晋级策略
镜像是不可变的:同一个镜像 tag 在所有环境运行。环境差异体现在配置(ConfigMap/Secret/values),而不是代码。
# 错误做法(镜像与环境耦合)❌
myapp:dev-latest
myapp:staging-latest
myapp:prod-latest
# 正确做法(镜像不可变)✅
myapp:a3f1c8b # Git commit SHA
myapp:v1.2.3 # Semantic version
CI 构建镜像并更新 infra-repo
# .github/workflows/ci.yml
name: Build and Deploy
on:
push:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
outputs:
image_tag: ${{ steps.meta.outputs.tags }}
sha: ${{ github.sha }}
steps:
- uses: actions/checkout@v4
- name: 构建并推送镜像
id: build
uses: docker/build-push-action@v5
with:
context: .
push: true
tags: |
myorg/api:${{ github.sha }}
myorg/api:latest
deploy-dev:
needs: build
runs-on: ubuntu-latest
steps:
- name: 更新 Dev 环境镜像 tag
uses: actions/checkout@v4
with:
repository: myorg/infra-repo
token: ${{ secrets.INFRA_REPO_TOKEN }}
- name: 更新 kustomize image
run: |
cd apps/api/overlays/dev
kustomize edit set image myorg/api=myorg/api:${{ github.sha }}
git add .
git commit -m "ci: deploy api ${{ github.sha }} to dev"
git push
# ArgoCD 自动同步 dev,然后运行集成测试
integration-tests:
needs: deploy-dev
runs-on: ubuntu-latest
steps:
- name: 等待 dev 部署完成
run: |
argocd app wait api-dev --health --timeout 300
- name: 运行集成测试
run: |
npm run test:integration -- --env=dev
deploy-staging:
needs: integration-tests
runs-on: ubuntu-latest
steps:
- name: 晋级到 staging
run: |
cd apps/api/overlays/staging
kustomize edit set image myorg/api=myorg/api:${{ github.sha }}
git add .
git commit -m "ci: promote api ${{ github.sha }} to staging"
git push
GitHub Environments:生产审批门禁
# .github/workflows/deploy-prod.yml
name: Deploy to Production
on:
workflow_dispatch:
inputs:
image_tag:
description: 'Image tag to deploy'
required: true
jobs:
deploy-production:
runs-on: ubuntu-latest
environment: production # 需要在 GitHub Settings 配置审批人
steps:
- name: 部署到生产环境
run: |
cd apps/api/overlays/production
kustomize edit set image myorg/api=myorg/api:${{ inputs.image_tag }}
git commit -m "deploy: api ${{ inputs.image_tag }} to production"
git push
GitHub Environment production 配置:
- Required reviewers:至少 2 人审批
- Wait timer:推送到 staging 后等待 30 分钟(监控稳定性)
- Deployment branches:只允许 main 分支触发
金丝雀发布(Canary Release)
不一次性全量替换,先让小比例流量走新版本:
# 使用 Argo Rollouts 实现金丝雀
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: api-rollout
namespace: production
spec:
replicas: 10
selector:
matchLabels:
app: api-server
template:
metadata:
labels:
app: api-server
spec:
containers:
- name: api
image: myorg/api:v1.3.0
strategy:
canary:
steps:
- setWeight: 10 # 步骤 1:10% 流量到新版本
- pause: { duration: 5m } # 观察 5 分钟
- analysis: # 自动分析成功率
templates:
- templateName: success-rate-analysis
- setWeight: 30 # 步骤 2:30% 流量
- pause: { duration: 5m }
- setWeight: 60
- pause: { duration: 10m }
- setWeight: 100 # 最终全量
# AnalysisTemplate:自动决策金丝雀是否健康
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
name: success-rate-analysis
namespace: production
spec:
metrics:
- name: success-rate
successCondition: result[0] >= 0.95
failureCondition: result[0] < 0.90
provider:
prometheus:
address: http://prometheus.monitoring:9090
query: |
sum(rate(http_requests_total{status_code=~"2.."}[5m]))
/
sum(rate(http_requests_total[5m]))
完整 GitOps 晋级流程总结
┌─────────────────────────────────────────────────────────────────┐
│ 代码合并到 main 分支 │
└────────────────────────────┬────────────────────────────────────┘
│ CI 触发
▼
┌─────────────────────────────────────────────────────────────────┐
│ 1. 构建镜像(myorg/api:abc1234) │
│ 2. 更新 infra-repo dev 环境 image tag │
│ 3. ArgoCD 自动同步 dev 集群(selfHeal=true) │
│ 4. 运行自动化测试(集成/E2E) │
└────────────────────────────┬────────────────────────────────────┘
│ 测试通过
▼
┌─────────────────────────────────────────────────────────────────┐
│ 5. 更新 infra-repo staging 环境 image tag │
│ 6. ArgoCD 自动同步 staging 集群 │
│ 7. 监控 30 分钟(错误率/延迟 SLO) │
└────────────────────────────┬────────────────────────────────────┘
│ 稳定 + 人工审批
▼
┌─────────────────────────────────────────────────────────────────┐
│ 8. GitHub Environment 审批(2 人) │
│ 9. 更新 infra-repo production 环境 image tag │
│ 10. ArgoCD 手动同步(Manual syncPolicy) │
│ 11. Argo Rollouts 金丝雀:10% → 30% → 100% │
│ 12. 每步自动分析 Prometheus 指标决定是否继续 │
└─────────────────────────────────────────────────────────────────┘
回滚决策矩阵
| 情况 | 回滚方式 | 时间 |
|---|---|---|
| 金丝雀阶段发现问题 | Argo Rollouts 自动终止 | < 1 分钟 |
| 全量后发现问题 | git revert + ArgoCD 同步 | 3-5 分钟 |
| 数据库 Schema 问题 | helm rollback + 数据库回滚脚本 | 15-30 分钟 |
| 灾难性故障 | Velero 备份恢复 | 30-60 分钟 |
下一章:IaC 安全、合规与代码审查