10.2 部署流程与最佳实践


文档摘要

10.2 部署流程与最佳实践 本节摘要:部署不该是"登录服务器手敲一串命令",而应是一段可重复执行的固定流程:拉代码、装依赖、跑测试、迁移、收集静态、重启服务。本节把发布固化为脚本、谈环境变量管理、迁移与发布的顺序设计、回滚预案,最后给出首发验证清单。 发布四步曲(加两拍) 墨迹博客的每次发布都执行同一段序列: 顺序有讲究:测试在迁移前——测试不过,数据库一个字节不动;迁移在重启前——新代码重启前表结构先就位,避免新进程访问旧结构。reload 而非 restart:worker 逐个换新,旧请求处理完再退,用户几乎无感。 这段序列保存成一段 shell 脚本,发布从"技术动作"变成"管理动作"。再往前一步接入持续集成:仓库推送触发流水线自动执行一到三步,人工只按最后的生产按钮。

10.2 部署流程与最佳实践

本节摘要:部署不该是"登录服务器手敲一串命令",而应是一段可重复执行的固定流程:拉代码、装依赖、跑测试、迁移、收集静态、重启服务。本节把发布固化为脚本、谈环境变量管理、迁移与发布的顺序设计、回滚预案,最后给出首发验证清单。

发布四步曲(加两拍)

墨迹博客的每次发布都执行同一段序列:

# 一 拉取指定版本(永远不部署"最新",部署"指定") git fetch && git checkout v1.4.2 # 二 依赖对齐 pip install -r requirements.txt # 三 测试闸门(第9章的成果在此上岗) python manage.py test # 四 数据库迁移 python manage.py migrate # 五 静态收集 python manage.py collectstatic --noinput # 六 平滑重启 sudo systemctl reload gunicorn

顺序有讲究:测试在迁移前——测试不过,数据库一个字节不动;迁移在重启前——新代码重启前表结构先就位,避免新进程访问旧结构。reload 而非 restart:worker 逐个换新,旧请求处理完再退,用户几乎无感。

这段序列保存成一段 shell 脚本,发布从"技术动作"变成"管理动作"。再往前一步接入持续集成:仓库推送触发流水线自动执行一到三步,人工只按最后的生产按钮。流水线不必一步到位,但脚本化是底线——凡是靠记忆执行的流程,早晚会漏一步

发布流水线

发布流水线

环境变量:每个环境一份姿态

密钥、数据库地址、调试开关按环境隔离,配置从进程环境读取。管理方式从轻到重:托管平台的变量面板、服务器上的环境文件(进程管理器加载,权限收紧)、集中式密钥管理。原则两条:同一份代码跑所有环境,只换环境变量环境文件绝不进版本库(依赖清单加忽略规则)。

由此还能派生一个开发期好习惯:本地用默认值、生产强制注入:

SECRET_KEY = os.environ.get( "DJANGO_SECRET_KEY", "dev-only-insecure-key")

开发零配置、生产无默认可退——忘了注入,启动即报错提示,而不是带着弱密钥悄悄上线。

迁移与发布的顺序设计

第 2 章的迁移纪律在发布流程里兑现成两条设计:

兼容迁移优先。一次发布里既加字段又删字段时,分两次发布:第一次只加(旧代码忽略新列,无感),第二次再删(此时线上已无代码读旧列)。一步到位的"加删混合"会在重启窗口内让旧 worker 访问不存在的列。

破坏性迁移挑低峰。加索引在大表上可能锁表数分钟,sqlmigrate 预览加低峰执行是底线动作,重要表用"分步建索引"策略(先建 concurrently 类的无锁方案,视数据库方言)。

回滚:为最坏情况做预案

发布前想清楚"怎么退"。应用层回滚很便宜:切回上一版本标签,重跑依赖与静态收集,重启。数据层回滚昂贵,所以:

  • 迁移脚本写反向操作(第 2 章 RunPython 的第二个函数就是为此留位);
  • 发布前备份数据库,恢复演练至少做过一次;
  • 兼容式发布让"回滚应用不回滚数据"成为常态。

首发验证清单

墨迹博客首发当晚按单核对:首页与详情页正常返回;HTTPS 证书与跳转生效;静态文件由 Nginx 服务(响应头里的服务方可见);登录、发文、评论三条主路径走通;Admin 可登录且限 HTTPS;错误页(404、500)是自定义页面而非调试页;日志文件在增长、无异常刷屏;监控探活有响应。

💡 上线后的第一小时别离开键盘:盯日志与基础指标,比任何事后复盘都值钱。

发布节奏与灰度心态

发布流程跑顺之后,下一个进阶话题是发布节奏。刚上线的项目常在两个极端间摇摆:要么不敢发,攒两个月的改动一次性上线,结果发布清单长到没人敢拍板,出问题也定位不出是哪次改动引入;要么发太随意,任何时点想发就发,某次周五晚上的小改动在周末放大成事故。健康的节奏取中间:固定发布窗口(比如每周两次),每次改动量适中,发布前有清单、发布后有验证窗口,重大变更避开业务高峰与假期前夜。进阶做法是灰度——新版本先接一小部分流量,观察错误率与性能指标无异常再全量。对单机项目,灰度的最简形态是先发非关键页面相关的功能,核心路径的功能单独发。发布的工程学目标可以一句话概括:让每次上线都无聊。刺激的发布不是勋章,是隐患。

本节要点回顾

  • 发布是一段脚本不是一串记忆:拉版本、依赖、测试、迁移、静态、平滑重启,顺序有因果。
  • 测试闸门在迁移之前,库的结构只在闸门后变动。
  • 兼容式分步发布让回滚只需回应用,数据不动。
  • 首发清单逐项核对,第一小时盯日志。

应用上线了,项目进入维护期。下一章处理维护期的两大主题:让它快(缓存与调优)、让它省(异步任务)。


作者与出处
原作者: 灏天文库
来源:灏天文库
整理: 灏天文库整理
由灏天文库平台收录,内容或由平台用户上传,仅供学习交流
发布者: 作者: 灏天文库 转发
评论区 (0)
U