持续集成与发布流程

学习目标

让每次代码变更自动运行 SQLite/MySQL 测试，建立包含备份、迁移、静态资源和健康检查的发布步骤，区分代码回退与数据库回退。

为什么测试应在发布前运行

开发机可能留有未提交迁移或额外依赖，只有从干净代码和新环境安装，才能发现“仅在我的电脑可用”的问题。CI 不访问生产数据库，MySQL 服务是临时实例，测试后销毁。流水线中的示例 root 密码只属于这个隔离服务，不能复制为生产凭据。

数据库迁移可能不可逆，回退 Git 不会自动恢复字段或数据。发布前应检查迁移计划和恢复方案；新增列、回填和删除旧列适合拆成兼容阶段，减少旧代码与新表结构之间的窗口风险。

具体怎么做

1. 将完整练习项目推到自己的 GitHub 仓库，保存工作流文件。
2. SQLite 作业检查系统、迁移漂移和测试；MySQL 作业验证同一套业务测试在真实引擎的行为。
3. 上线前先完成下一章的备份与演练，再在维护窗口执行 release.sh。脚本不会自动 git pull，管理员应先确认目标提交与审查结果。
4. 脚本先构建与检查，再停 Web 执行迁移和静态收集。若这几步失败，保持停止状态以便人工判断，避免带着半完成环境继续接收写入。

本章新增或替换的完整文件

以下路径均相对于练习项目根目录。替换同名文件的全部内容；未列出的文件保持上一章版本。

.github/workflows/test.yml

name: 知行博客回归检查
on: [push, pull_request]
jobs:
  sqlite:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: {python-version: '3.14'}
      - run: python -m pip install -r requirements.txt
      - run: python manage.py check --settings=config.test_settings
      - run: python manage.py makemigrations --check --dry-run --settings=config.test_settings
      - run: python manage.py test --settings=config.test_settings
  mysql:
    runs-on: ubuntu-latest
    services:
      mysql:
        image: mysql:8.4
        env:
          MYSQL_ROOT_PASSWORD: ci-isolated-only
          MYSQL_DATABASE: zhixing_test_source
        ports: ['3306:3306']
        options: >-
          --health-cmd="mysqladmin ping -h127.0.0.1 --silent"
          --health-interval=10s --health-timeout=5s --health-retries=30
    env:
      MYSQL_TEST_USER: root
      MYSQL_TEST_PASSWORD: ci-isolated-only
      MYSQL_TEST_HOST: 127.0.0.1
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: {python-version: '3.14'}
      - run: sudo apt-get update && sudo apt-get install -y pkg-config default-libmysqlclient-dev build-essential
      - run: python -m pip install -r requirements-mysql.txt
      - run: python manage.py test --settings=config.mysql_test_settings

deploy/release.sh

#!/usr/bin/env bash
set -euo pipefail
cd "$(dirname "$0")/.."
# 先完成第 34 章备份，确认已拉取并审核本次代码，再执行此脚本。
docker compose build web
docker compose run --rm web python manage.py check
docker compose run --rm web python manage.py makemigrations --check --dry-run
docker compose stop web
# 失败时保持停止，保留旧镜像和备份，由管理员判断数据库是否可回退。
docker compose run --rm --no-deps web python manage.py migrate --noinput
docker compose run --rm --no-deps web python manage.py collectstatic --noinput
docker compose up -d web nginx
docker compose exec -T web python -c "import urllib.request; print(urllib.request.urlopen('http://127.0.0.1:8000/health/').status)"

如何确认成功

GitHub Actions 两个作业通过，日志没有“检测到未提交模型变化”。本地也应能复现：

python manage.py makemigrations --check --dry-run
python manage.py test --settings=config.test_settings
bash -n deploy/release.sh

发布演练只在自己的测试部署执行：

bash deploy/release.sh
docker compose ps

脚本结束后健康接口为 200，再手工验证首页、登录、写作、图片和 API。健康检查并不能替代业务验收。如果启用了 HTTPS，先按上一章设置相同的 COMPOSE_FILE。

练习：给发布记录写上提交号、迁移列表、备份标识和验收人。模拟代码错误但数据库兼容时恢复旧镜像；再讨论删除列后为什么不能仅切回旧镜像。

常见问题

CI 成功能自动上线吗？ 可以设计，但本教程先保留人工发布，只有完整掌握密钥、审批和回退后再自动化。失败了直接重复脚本？ 先确认失败步骤和数据库状态，尤其不要盲目反复执行有副作用的数据迁移。测试很多是不是可以不做备份？ 不能，测试验证行为，备份解决数据恢复。

官方参考

• GitHub Python 工作流
• 迁移操作与可逆性