225 lines
5.0 KiB
Markdown
225 lines
5.0 KiB
Markdown
# 六壬神鉴渐进发布计划
|
||
|
||
## 概述
|
||
本计划基于当前的多环境 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
|
||
- 紧急热线: [待填写]
|
||
|
||
## 持续改进
|
||
|
||
### 发布回顾
|
||
每次发布后一周内进行回顾会议：
|
||
- 分析发布过程中的问题
|
||
- 收集用户反馈
|
||
- 更新发布流程
|
||
- 优化监控指标
|
||
|
||
### 自动化改进
|
||
- 逐步增加自动化测试覆盖率
|
||
- 完善监控和告警系统
|
||
- 优化部署脚本
|
||
- 建立自动化回滚机制 |