技术文章发布系统 - Git分支与回滚策略

1. Git分支策略设计1.1 主分支结构main (主分支) ├── develop (开发分支) │ ├── feature/article-template (功能分支) │ ├── feature/review-system (功能分支) │ ├── feature/seo-optimization (功能分支) │ └── feature/batch-tools (功能分支) ├── release/v1.0.0 (发布分支) ├── hotfix/critical-bug (热修复分支) └── hotfix/security-patch (安全修复分支) 1.2 分支命名规范功能分支（Feature Branches）命名格式：`feature/功能描述`示例：`feature/article-template`、`feature/review-system`用途：开发新功能源分支：develop目标分支：develop发布分支（Release Branches）命名格式：`release/版本号`示例：`release/v1.0.0`、`release/v1.1.0`用途：准备发布新版本源分支：develop目标分支：main热修复分支（Hotfix Branches）命名格式：`hotfix/修复描述`示例：`hotfix/critical-bug`、`hotfix/security-patch`用途：修复生产环境的紧急问题源分支：main目标分支：main 和 develop支持分支（Support Branches）命名格式：`support/支持描述`示例：`support/legacy-compatibility`用途：为旧版本提供支持源分支：main1.3 分支权限管理主分支保护规则# .github/workflows/branch-protection.yml name: Branch Protection Rules on: pull_request: branches: [ main, develop ] jobs: protect-main-branch: runs-on: ubuntu-latest steps: - name: Check PR source branch run: | # 只允许从release和hotfix分支合并到main if [[ "${{ github.head_ref }}" != release/* ]] && [[ "${{ github.head_ref }}" != hotfix/* ]]; then echo "❌ 只能从release或hotfix分支合并到main分支" exit 1 fi - name: Require PR reviews uses: hmarr/auto-approve-action@v2 with: review-requirement: 2 # 需要2个review - name: Require status checks uses: github/require-status-checks-action@v1 with: required_status_checks: | build test lint security-scan 2. 工作流程规范2.1 功能开发流程# 1. 从develop分支创建功能分支 git checkout develop git pull origin develop git checkout -b feature/article-template # 2. 开发完成后推送到远程 git add . git commit -m "feat: 新增文章模板功能 - 添加多种文章模板 - 支持模板自定义 - 优化模板渲染性能 Closes #123" git push origin feature/article-template # 3. 创建Pull Request到develop分支 # 在GitHub上创建PR，填写模板信息 # 4. Code Review通过后合并 git checkout develop git merge --no-ff feature/article-template git push origin develop # 5. 删除功能分支 git branch -d feature/article-template git push origin --delete feature/article-template 2.2 发布流程# 1. 创建发布分支 git checkout develop git pull origin develop git checkout -b release/v1.0.0 # 2. 更新版本号和文档 # 修改 package.json, CHANGELOG.md等文件 # 3. 修复测试中发现的问题（不添加新功能） # 提交修复 commit git commit -m "fix: 修复发布前的已知问题" # 4. 合并到main分支 git checkout main git merge --no-ff release/v1.0.0 git tag -a v1.0.0 -m "Release version 1.0.0" git push origin main --tags # 5. 合并回develop分支 git checkout develop git merge --no-ff release/v1.0.0 git push origin develop # 6. 删除发布分支 git branch -d release/v1.0.0 git push origin --delete release/v1.0.0 2.3 热修复流程# 1. 创建热修复分支 git checkout main git pull origin main git checkout -b hotfix/critical-bug # 2. 修复问题并提交 git commit -m "fix: 修复关键bug - 修复文章发布失败问题 - 优化错误处理逻辑 Hotfix: #456" # 3. 测试通过后合并到main git checkout main git merge --no-ff hotfix/critical-bug git tag -a v1.0.1 -m "Hotfix version 1.0.1" git push origin main --tags # 4. 合并到develop分支 git checkout develop git merge --no-ff hotfix/critical-bug git push origin develop # 5. 删除热修复分支 git branch -d hotfix/critical-bug git push origin --delete hotfix/critical-bug 3. 回滚策略3.1 代码回滚策略场景一：回滚到上一个稳定版本# 查看提交历史 git log --oneline -10 # 方法1：使用git revert（推荐，不会丢失历史） git revert HEAD~3..HEAD # 回滚最近3个commit # 方法2：使用git reset（会丢失历史，谨慎使用） git reset --hard HEAD~3 # 回退到前3个commit git push origin main --force # 需要强制推送 # 方法3：回滚到指定的tag git checkout v1.0.0 git checkout -b rollback-to-v1.0.0 git checkout main git reset --hard rollback-to-v1.0.0 git push origin main --force 场景二：回滚单个有问题的commit# 找到有问题的commit ID git log --oneline # 使用git revert回滚指定的commit git revert <commit-id> # 如果有冲突，解决冲突后 git add . git commit -m "Revert \"有问题的commit消息\"" git push origin main 场景三：回滚已经合并的PR# 找到合并PR时产生的merge commit git log --oneline --grep="Merge pull request" # 回滚merge commit git revert -m 1 <merge-commit-id> # 解释：-m 1 表示保留main分支的更改，回滚被合并的分支 3.2 数据库回滚策略数据库迁移回滚// 在迁移文件中添加回滚逻辑 exports.up = function(knex) { return knex.schema.createTable('articles', function(table) { table.increments('id'); table.string('title'); table.text('content'); table.timestamps(); }); }; exports.down = function(knex) { return knex.schema.dropTable('articles'); }; // 回滚命令 // knex migrate:rollback // knex migrate:rollback --all // 回滚所有迁移 数据备份回滚#!/bin/bash # 数据库备份和回滚脚本 # 备份数据库 backup_database() { DATE=$(date +%Y%m%d_%H%M%S) BACKUP_FILE="backup_${DATE}.sql" pg_dump -h localhost -U postgres article_system > "${BACKUP_FILE}" echo "数据库备份完成: ${BACKUP_FILE}" } # 回滚数据库 rollback_database() { BACKUP_FILE=$1 if [ -f "${BACKUP_FILE}" ]; then psql -h localhost -U postgres -d article_system < "${BACKUP_FILE}" echo "数据库回滚完成: ${BACKUP_FILE}" else echo "备份文件不存在: ${BACKUP_FILE}" exit 1 fi } # 使用示例 backup_database # rollback_database "backup_20241201_120000.sql" 3.3 文件系统回滚策略使用Git LFS管理大文件# 安装Git LFS git lfs install # 跟踪大文件类型 git lfs track "*.pdf" git lfs track "*.zip" git lfs track "images/*.png" # 提交后，大文件会被存储在LFS中 git add .gitattributes git add images/large-file.png git commit -m "Add large image file" # 回滚大文件版本 git log --follow -- images/large-file.png git checkout <commit-id> -- images/large-file.png 使用版本控制系统管理配置文件# docker-compose.yml 版本管理 version: '3.8' services: app: image: article-system:${VERSION:-latest} volumes: - ./config:/app/config - ./uploads:/app/uploads - ./backups:/app/backups environment: - NODE_ENV=production - VERSION=${VERSION} 4. 自动化回滚机制4.1 CI/CD流水线回滚# .github/workflows/rollback.yml name: Automated Rollback on: workflow_dispatch: inputs: version: description: 'Version to rollback to' required: true type: string environment: description: 'Environment' required: true type: choice options: - staging - production jobs: rollback: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v3 with: fetch-depth: 0 - name: Rollback application run: | # 回滚代码到指定版本 git checkout ${{ github.event.inputs.version }} # 构建回滚版本 npm ci npm run build # 部署回滚版本 npm run deploy:${{ github.event.inputs.environment }} - name: Rollback database if: ${{ github.event.inputs.environment == 'production' }} run: | # 数据库回滚 npm run db:rollback:to ${{ github.event.inputs.version }} - name: Verify rollback run: | # 健康检查 npm run health:check # 如果健康检查失败，发送警报 if [ $? -ne 0 ]; then npm run alert:rollback:failed exit 1 fi - name: Notify rollback result run: | # 发送回滚结果通知 npm run notify:rollback:success 4.2 监控告警触发回滚// 监控告警配置 const rollbackConfig = { triggers: { errorRate: { threshold: 0.05, // 错误率超过5% duration: 300, // 持续5分钟 action: 'rollback' }, responseTime: { threshold: 5000, // 响应时间超过5秒 duration: 600, // 持续10分钟 action: 'rollback' }, availability: { threshold: 0.95, // 可用性低于95% duration: 180, // 持续3分钟 action: 'rollback' } }, rollbackStrategy: { automatic: true, maxRollbackTime: 3600, // 最大回滚时间1小时 notifyChannels: ['email', 'slack', 'sms'], approvalRequired: false // 紧急情况下自动回滚 } }; // 自动回滚逻辑 async function autoRollback(metric, threshold) { const deployments = await getRecentDeployments(5); const previousStableVersion = deployments[1]; // 上一个稳定版本 console.log(`触发自动回滚: ${metric}超过阈值${threshold}`); console.log(`回滚到版本: ${previousStableVersion}`); try { await triggerRollback(previousStableVersion); await notifyRollbackSuccess(previousStableVersion); } catch (error) { console.error('自动回滚失败:', error); await notifyRollbackFailure(error); } } 5. 回滚最佳实践5.1 回滚前检查清单## 回滚前检查清单 ### 技术检查 - [ ] 确认回滚目标版本 - [ ] 检查回滚版本的功能完整性 - [ ] 验证数据库兼容性 - [ ] 确认配置文件兼容性 - [ ] 检查依赖项版本 ### 业务检查 - [ ] 评估回滚影响范围 - [ ] 通知相关业务方 - [ ] 准备回滚后验证方案 - [ ] 制定紧急恢复计划 - [ ] 确认维护时间窗口 ### 数据检查 - [ ] 备份当前数据 - [ ] 确认数据迁移脚本 - [ ] 检查数据一致性 - [ ] 验证回滚后数据完整性 5.2 回滚后验证#!/bin/bash # 回滚后验证脚本 echo "开始回滚后验证..." # 1. 服务健康检查 echo "1. 检查服务健康状态..." curl -f http://localhost:3000/health || exit 1 # 2. 数据库连接检查 echo "2. 检查数据库连接..." node -e " const { Pool } = require('pg'); const pool = new Pool({ connectionString: process.env.DATABASE_URL }); pool.query('SELECT 1', (err, res) => { if (err) { console.error('数据库连接失败:', err); process.exit(1); } console.log('数据库连接正常'); pool.end(); }); " # 3. 核心功能测试 echo "3. 测试核心功能..." npm run test:core # 4. 性能基准测试 echo "4. 性能基准测试..." npm run test:performance # 5. 生成验证报告 echo "5. 生成验证报告..." npm run generate:rollback:report echo "回滚验证完成！" 5.3 回滚记录和复盘# 回滚记录模板 ## 回滚基本信息 - 回滚时间：2024-12-01 15:30:00 - 回滚原因：新版本导致文章发布功能异常 - 回滚版本：从v1.2.0回滚到v1.1.5 - 执行人：张三 - 回滚耗时：15分钟 ## 影响范围 - 受影响功能：文章发布、编辑、审核 - 受影响用户：所有内容创作者 - 业务影响：无法发布新文章，编辑功能异常 - 数据影响：无数据丢失 ## 回滚过程 1. 15:25 - 发现问题，评估需要回滚 2. 15:27 - 备份当前数据和配置 3. 15:30 - 开始执行回滚 4. 15:35 - 代码回滚完成 5. 15:40 - 数据库回滚完成 6. 15:42 - 服务重启，验证功能 7. 15:45 - 回滚完成，功能恢复 ## 经验教训 ### 做得好的地方 - 监控系统及时发现问题 - 回滚流程执行顺利 - 数据备份完整 ### 需要改进的地方 - 新版本测试不充分 - 灰度发布范围太小 - 回滚自动化程度不够 ## 后续行动计划 1. 加强新版本测试流程 2. 扩大灰度发布范围 3. 完善自动化回滚机制 4. 增加更多的监控指标