ben/liurenchaxin
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

feat: 配置金丝雀/开发/测试渐进发布环境

Browse Source 
- 添加渐进发布脚本和文档
- 配置canary/dev/beta三环境部署策略
- 包含快速发布、回滚和状态检查功能
This commit is contained in:
ben
2025-08-30 14:40:02 +00:00
parent f65ef78d10
commit cf14f606db
7 changed files with 855 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

102
docs/development/CANARY_DEV_BETA_DEPLOYMENT.md Normal file
View File

@@ -0,0 +1,102 @@
# 金丝雀/开发/测试部署策略
## 环境命名
根据新的命名约定，三个环境重新命名为：
- **canary** (金丝雀环境): `https://gitea.tailnet-68f9.ts.net/gitea/liurenchaxin.git`
- **dev** (开发环境): `git@bitbucket.org:capitaltrain/liurenchaxin.git`
- **beta** (测试环境): `https://github.com/jingminzhang/taigongxinyi.git`
## 环境用途
- **canary (金丝雀)**: 最新功能测试，早期验证
- **dev (开发)**: 功能开发和集成测试
- **beta (测试)**: 预发布测试，用户验收
## 部署流程
### 1. 日常开发流程
```bash
# 在 canary 环境开发新功能
git checkout develop
git pull canary develop
# 开发完成后
git add .
git commit -m "feat: 新功能描述"
git push canary develop
```
### 2. 集成测试流程
```bash
# 将功能从 canary 推送到 dev 环境
git checkout dev
git pull dev main
git merge develop
git push dev dev:main
```
### 3. 预发布流程
```bash
# 将功能从 dev 推送到 beta 环境
git checkout main
git pull beta main
git merge dev
git push beta main
```
## 快速命令
### 发布新版本
```bash
# 金丝雀环境发布
./scripts/quick-release.sh 1.2.3 canary
# 开发环境发布
./scripts/quick-release.sh 1.2.3 dev
# 测试环境发布
./scripts/quick-release.sh 1.2.3 beta
```
### 回滚操作
```bash
# 回滚金丝雀环境
./scripts/rollback.sh canary 1.2.2
# 回滚开发环境
./scripts/rollback.sh dev 1.2.2
# 回滚测试环境
./scripts/rollback.sh beta 1.2.2
```
### 状态检查
```bash
./scripts/check-status.sh
```
## 分支策略
- **develop**: 金丝雀环境主分支
- **dev**: 开发环境主分支
- **main**: 测试环境主分支
## 标签命名
- 金丝雀: `v1.2.3-canary`
- 开发: `v1.2.3-dev`
- 测试: `v1.2.3-beta`
## 优势
1. **清晰的命名**: canary/dev/beta 更符合行业标准
2. **渐进发布**: 从金丝雀到测试的渐进式验证
3. **快速回滚**: 每个环境都可以独立回滚
4. **隔离性好**: 不同环境完全隔离，减少干扰

196
docs/development/DEPLOYMENT_FLOW.md Normal file
View File

@@ -0,0 +1,196 @@
# 六壬神鉴渐进发布流程图
## 🎯 发布流程概览
```
┌─────────────────┐ ┌──────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Development │ │ Staging │ │ Canary │ │ Production │
│ (Gitea) │───▶│ (Bitbucket) │───▶│ (GitHub 10%) │───▶│ (GitHub 100%) │
│ develop分支 │ │ staging分支 │ │ main分支 │ │ main分支 │
└─────────────────┘ └──────────────────┘ └─────────────────┘ └─────────────────┘
│ │ │ │
│ │ │ │
▼ ▼ ▼ ▼
┌─────────────────┐ ┌──────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ 功能开发 │ │ 集成测试 │ │ 灰度验证 │ │ 全量发布 │
│ 单元测试 │ │ 性能测试 │ │ 监控验证 │ │ 持续监控 │
│ 代码审查 │ │ 安全扫描 │ │ 用户反馈 │ │ 性能优化 │
└─────────────────┘ └──────────────────┘ └─────────────────┘ └─────────────────┘
```
## 🚀 快速操作指南
### 1. 日常开发流程
#### 开始新功能开发
```bash
# 从 develop 分支创建功能分支
git checkout develop
git pull origin develop
git checkout -b feature/new-feature
# 开发完成后
git add .
git commit -m "feat: 添加新功能"
git push origin feature/new-feature
# 创建 PR 到 develop 分支
# 在 Gitea 上创建 Pull Request
```
#### 推送到开发环境
```bash
# 一键推送到 Gitea 开发环境
git checkout develop
git pull origin develop
git merge feature/new-feature
git push gitea develop
```
### 2. 预发布流程
#### 准备 staging 发布
```bash
# 创建发布分支
git checkout staging
git merge develop
git push staging staging:main
# 或使用快捷命令
git deploy-staging
```
#### 验证 staging 环境
```bash
# 检查 staging 状态
./scripts/check-status.sh
```
### 3. 灰度发布流程
#### 启动灰度发布
```bash
# 创建灰度版本
git checkout main
git merge staging
git tag v1.2.0-canary
git push origin main --tags
```
#### 监控灰度状态
```bash
# 检查发布状态
curl -s https://api.github.com/repos/jingminzhang/taigongxinyi/releases/latest
```
### 4. 全量发布流程
#### 正式版本发布
```bash
# 使用快速发布脚本
./scripts/quick-release.sh 1.2.0 prod
# 或手动操作
git checkout main
git tag v1.2.0
git push origin main --tags
git deploy-prod
```
## 📊 发布检查清单
### 开发阶段检查
- [ ] 代码通过单元测试
- [ ] 功能测试完成
- [ ] 代码审查通过
- [ ] 文档已更新
### Staging 阶段检查
- [ ] 集成测试通过
- [ ] 性能测试完成
- [ ] 安全扫描通过
- [ ] 用户验收测试完成
### 灰度发布检查
- [ ] 监控指标正常
- [ ] 错误率 < 0.1%
- [ ] 用户反馈良好
- [ ] 业务指标稳定
### 全量发布检查
- [ ] 灰度验证通过
- [ ] 回滚方案就绪
- [ ] 监控告警配置
- [ ] 紧急联系清单
## 🔄 回滚操作
### 紧急回滚
```bash
# 快速回滚到指定版本
./scripts/rollback.sh prod 1.1.9
# 或手动回滚
git checkout v1.1.9
git tag v1.2.0-rollback
git push origin main --force
```
### 回滚验证
```bash
# 检查回滚状态
./scripts/check-status.sh
```
## 📈 监控面板
### 关键指标监控
- **系统性能**: CPU、内存、磁盘使用率
- **应用性能**: 响应时间、吞吐量、错误率
- **业务指标**: 用户活跃度、功能使用率
### 告警规则
- 错误率 > 1% → 立即告警
- 响应时间 > 1s → 立即告警
- 服务不可用 → 立即告警
## 🛠️ 工具命令速查
| 操作 | 命令 | 说明 |
|------|------|------|
| 查看状态 | `./scripts/check-status.sh` | 检查所有环境状态 |
| 快速发布 | `./scripts/quick-release.sh 版本号 环境` | 一键发布到指定环境 |
| 紧急回滚 | `./scripts/rollback.sh 环境 版本号` | 快速回滚到指定版本 |
| 推送到 staging | `git deploy-staging` | 推送到 Bitbucket staging |
| 推送到 prod | `git deploy-prod` | 推送到 GitHub production |
| 同步所有远程 | `git sync-all` | 同步所有远程仓库 |
## 📞 紧急联系
| 角色 | 联系方式 | 职责 |
|------|----------|------|
| 技术负责人 | ben@capitaltrain.cn | 技术决策、紧急响应 |
| 运维团队 | ops@capitaltrain.cn | 部署、监控、故障处理 |
| 产品团队 | product@capitaltrain.cn | 业务决策、用户沟通 |
## 🎓 最佳实践
### 1. 分支管理
- 功能分支从 `develop` 创建
- 发布分支从 `staging` 创建
- 热修复分支从 `main` 创建
### 2. 版本命名
- 主版本: 不兼容的重大更新
- 次版本: 向后兼容的功能添加
- 修订版本: bug修复和微小改进
### 3. 发布频率
- 紧急修复: 随时发布
- 常规更新: 每2周一次
- 大版本更新: 每季度一次
### 4. 监控策略
- 灰度期间: 24-48小时密切监控
- 全量发布: 72小时持续监控
- 日常运维: 实时告警监控

225
docs/development/GRADUAL_DEPLOYMENT_PLAN.md Normal file
View File

@@ -0,0 +1,225 @@
# 六壬神鉴渐进发布计划
## 概述
本计划基于当前的多环境 Git 配置，实现从开发到生产的渐进式发布流程。
## 环境架构
### 当前配置
- **GitHub** (production): `https://github.com/jingminzhang/taigongxinyi.git`
- **Bitbucket** (staging): `git@bitbucket.org:capitaltrain/liurenchaxin.git`
- **Gitea** (development): `https://gitea.tailnet-68f9.ts.net/gitea/liurenchaxin.git`
### 分支策略
```
main (生产环境)
├── staging (预发布环境)
├── develop (开发环境)
└── feature/* (功能分支)
```
## 渐进发布阶段
### 阶段1：功能开发 (Development)
**目标环境**: Gitea (development)
**分支**: `feature/*` → `develop`
#### 流程
1. 从 `develop` 分支创建功能分支
2. 在功能分支上进行开发
3. 完成功能后合并到 `develop`
4. 推送到 Gitea 进行初步测试
#### 验证清单
- [ ] 单元测试通过
- [ ] 代码审查完成
- [ ] 功能测试通过
- [ ] 文档更新完成
### 阶段2：集成测试 (Staging)
**目标环境**: Bitbucket (staging)
**分支**: `develop` → `staging`
#### 流程
1. 从 `develop` 分支创建发布分支 `release/vX.Y.Z`
2. 在 staging 环境部署测试
3. 进行集成测试和用户验收测试
4. 修复发现的问题
5. 合并到 `staging` 分支
6. 推送到 Bitbucket staging 环境
#### 验证清单
- [ ] 集成测试通过
- [ ] 性能测试通过
- [ ] 安全扫描通过
- [ ] 用户验收测试完成
- [ ] 回滚方案准备就绪
### 阶段3：灰度发布 (Canary)
**目标环境**: GitHub production (10%流量)
**分支**: `staging` → `main`
#### 流程
1. 创建灰度发布标签 `vX.Y.Z-canary`
2. 部署到生产环境 10% 流量
3. 监控关键指标 24-48小时
4. 根据监控结果决定全量发布或回滚
#### 监控指标
- [ ] 错误率 < 0.1%
- [ ] 响应时间 < 500ms
- [ ] 用户满意度 > 95%
- [ ] 业务指标正常
### 阶段4：全量发布 (Production)
**目标环境**: GitHub production (100%流量)
**分支**: `main`
#### 流程
1. 创建正式版本标签 `vX.Y.Z`
2. 全量部署到生产环境
3. 持续监控 72小时
4. 准备热修复方案
## 发布策略
### 版本命名规范
- **主版本** (X.0.0): 重大功能更新或不兼容变更
- **次版本** (X.Y.0): 新功能添加，向后兼容
- **修订版本** (X.Y.Z): bug修复或小改进
### 发布频率
- **紧急修复**: 随时发布
- **常规更新**: 每2周一次
- **大版本更新**: 每季度一次
### 回滚策略
```bash
# 快速回滚到上一个版本
git revert HEAD
git push origin main --force
# 或使用标签回滚
git checkout vX.Y.Z-1
git tag -a vX.Y.Z-rollback -m "Rollback to vX.Y.Z-1"
git push origin vX.Y.Z-rollback
```
## 自动化工具
### Git 钩子配置
在 `.git/hooks/` 目录下创建以下钩子：
#### pre-push
```bash
#!/bin/bash
# 检查测试是否通过
pytest tests/
if [ $? -ne 0 ]; then
echo "测试未通过，禁止推送"
exit 1
fi
```
#### pre-commit
```bash
#!/bin/bash
# 代码格式检查
black --check .
flake8 .
```
### CI/CD 配置
创建 `.github/workflows/deploy.yml`：
```yaml
name: Gradual Deployment
on:
push:
branches: [staging, main]
release:
types: [published]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Run tests
run: |
python -m pytest tests/
deploy-staging:
needs: test
if: github.ref == 'refs/heads/staging'
runs-on: ubuntu-latest
steps:
- name: Deploy to staging
run: echo "Deploying to staging..."
deploy-production:
needs: test
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- name: Deploy to production
run: echo "Deploying to production..."
```
## 监控和告警
### 关键指标
- **系统指标**: CPU、内存、磁盘使用率
- **应用指标**: 响应时间、错误率、吞吐量
- **业务指标**: 用户活跃度、功能使用率
### 告警规则
- 错误率 > 1% 触发告警
- 响应时间 > 1秒 触发告警
- 服务不可用 立即告警
## 发布检查清单
### 发布前检查
- [ ] 所有测试通过
- [ ] 代码审查完成
- [ ] 文档已更新
- [ ] 数据库迁移脚本准备就绪
- [ ] 回滚方案已验证
### 发布后检查
- [ ] 服务正常启动
- [ ] 关键功能验证
- [ ] 监控数据正常
- [ ] 用户反馈收集
- [ ] 性能指标对比
## 紧急响应
### 故障处理流程
1. **发现故障** → 立即评估影响范围
2. **5分钟内** → 决定是否回滚
3. **10分钟内** → 执行回滚操作
4. **30分钟内** → 修复问题并验证
5. **1小时内** → 重新发布
### 联系方式
- 技术负责人: ben@capitaltrain.cn
- 运维团队: ops@capitaltrain.cn
- 紧急热线: [待填写]
## 持续改进
### 发布回顾
每次发布后一周内进行回顾会议：
- 分析发布过程中的问题
- 收集用户反馈
- 更新发布流程
- 优化监控指标
### 自动化改进
- 逐步增加自动化测试覆盖率
- 完善监控和告警系统
- 优化部署脚本
- 建立自动化回滚机制