软件部署流程图：从构建到生产环境
软件部署流程图：构建并给制品打上版本号、质量门、提升到制品库、预发布环境检查、灰度上线与自动回滚。
什么是软件部署流程图：从构建到生产环境流程
软件部署流程是把一个构建制品送到运行中的基础设施上的具体机制。它从一次合并开始，结束于某个版本完成上线，或者回滚到上一个版本。这让它有意比发布管理更窄：发布管理决定哪些内容属于本次发布、范围何时冻结，以及组织是否已经准备好交付。发布管理回答的是要不要发、发什么；部署回答的是怎么发。如果你们需要的那张图里有范围冻结、UAT 验收和一次放行与否的会议，那你们要的是发布流程。如果里面有制品版本、制品库、流量切换和回滚触发条件，那就来对地方了。它也不是 IT 变更管理：变更窗口以及开启它的那道审批，在这里只是两个步骤，而不是主题——因为这张图假定审批通道已经存在，它要展示的是部署在哪里等待它。
多数部署事故都能追溯到少数几条没有画出来的假设。制品在每个环境各自重新构建，于是通过了测试的东西，和最终进到生产环境的东西并不完全是同一个。预发布环境几个月前就已经偏离了生产环境的配置，因此一次全绿的冒烟测试所能证明的，比人们以为的要少。上线没有定义步长和观察时间，于是全部流量一次性切过去，而出问题的第一个信号是支持工单排起了队。还有，回滚触发条件是一个盯着仪表盘的人，而不是流水线自己就能判断的阈值——这就把一次快速而无聊的回滚，变成了一场讨论。把这条流程画成泳道之后，哪些步骤你们已经自动化、哪些仍然依赖有人记得，就一目了然了。
这份模板是一条可用的部署流程，横跨五条泳道——开发人员、CI/CD 流水线、QA、发布负责人与运维——铺排在从构建到生产环境上线的五个阶段上。它画出了通常不会被记录下来的三个回路：把失败的构建退回给开发人员、而不是让它继续往前走的质量门；在有人去预约变更窗口之前做同一件事的预发布环境检查；以及把已超出阈值的上线送回同一个缺陷修复步骤的自动回滚。它还把部署策略画成一个决策、而不是一条默认假设，于是蓝绿部署和灰度发布作为两条具名路径出现在图上，并在共同的流量切换与健康检查路径上重新汇合。
本流程图涵盖的内容
本模板包含
- 前两条泳道里的构建与版本：开发人员把变更合并到 main 分支，随后 CI/CD 流水线只构建一次制品，并把它标上所来自的提交，因此此后每一个环境部署的都是同一个制品。
- 质量门：流水线运行自动化测试与扫描，随后由 QA 拥有“是否通过质量门？”这个决策，它把失败导向“修复缺陷并重新构建”，而不是让它继续往前。
- 把提升与预发布环境画成两个彼此独立的步骤：制品被提升到制品库，由流水线部署到预发布环境，再由 QA 用冒烟测试与集成测试检查，然后才是“预发布环境是否健康？”这个决策——它失败的那条分支同样退回到缺陷修复。
- 带有真实否定结果的审批：发布负责人申请生产环境变更窗口，由运维作出“部署是否获批？”的判断，而不批准会让这次尝试终止于“部署推迟至下一个窗口”，而不是悄悄继续往下走。
- 被画成决策的部署策略：“蓝绿部署还是灰度发布？”分成部署到待机环境或部署到灰度实例，两条分支都在“结合健康检查切换流量”处重新汇合。
- 运维泳道里的回滚与收尾：“是否超出错误预算？”这个决策把失败的上线送往“回滚到上一个版本”并回到缺陷修复，而健康的上线则完成上线、持续监控，并关闭部署记录。
何时使用本模板
- 你们要为一个部署步骤只存在于一份流水线配置文件和少数几个人脑子里的团队，记录一次构建究竟是怎样进到生产环境的。
- 你们要在真的需要它之前就把回滚触发条件商定下来，让这个判断是一条量化阈值，而不是在最糟糕的时刻顶着压力作出的估计。
- 你们要为研发、QA 与值班人员做入职，他们需要知道自己拥有哪一道关口，以及当他们把这道关口关住时下游会发生什么。
- 你们要按服务逐个决定采用蓝绿部署还是灰度发布，并把这个选择记录在执行部署的人看得见的地方。
- 你们要回答审计师或客户关于一次变更是如何被测试、授权和撤销的问题，作为你们变更管理程序的补充。
运作方式
把泳道改成你们真实的角色
把开发人员、CI/CD 流水线、QA、发布负责人与运维换成你们实际拥有的角色。很多团队没有发布负责人，那就把这条泳道并入生产环境的责任人，而不是留下一条空带。即使 CI/CD 流水线是自动化的，也要把它保留为独立的一条泳道——这张图的意义正是展示哪些步骤由机器执行、哪些仍然由人执行。
写清楚制品是什么、放在哪里
写下制品类型（容器镜像、软件包、打包产物）、版本编号方案、版本是如何从提交推导出来的、由哪个制品库保存，以及保留多久。然后写下整张图其余部分所依赖的那条规则：只构建一次并提升同一个制品，绝不在每个环境各自重新构建。如果你们的流水线目前会重新构建，就把这一点标在图上，因为它切断了已测试内容与已交付内容之间的联系。
定义每一道关口究竟检查什么
“是否通过质量门？”的有用程度，取决于它的定义。写明哪些测试套件必须为绿、你们能接受的抖动率与覆盖率容忍度、哪些安全与依赖扫描会阻断构建，以及谁可以推翻一个红色结果。对预发布环境的冒烟测试与集成测试也做同样的事，并列出预发布环境与生产环境之间已知的差异（数据量、第三方沙箱、缩减规模的基础设施），让所有人都知道一次通过的预发布环境运行能证明什么、又不能证明什么。
定下变更窗口，以及由谁开启它
记录部署可以在什么时候执行、由谁批准，以及一次没有获批的部署会怎么样。写明这一类部署是在一份长期有效的变更模型下预先授权的，还是每次都需要一次单独的审批，并指名那位可以在正常工作时间之外批准部署的人。如果被推迟的部署只是等待下一个窗口，就写明制品在必须重新构建和重新测试之前还能有效多久。
按服务选一种策略，并写下上线步骤
为每个服务选择蓝绿部署或灰度发布，并把这个选择放到图上。然后写下它的机制：流量的递增幅度、每一步之间观察多久、每一步会运行哪些健康检查，以及灰度实例是拿来跟什么作对照的。数据库变更要单独处理，因为一次数据库结构迁移往往正是回滚不只是把开关拨回去的原因；把扩展式迁移与收缩式迁移同代码部署分开，可以让旧版本保持可运行。
让回滚触发条件可度量，然后把图发布出去
把“有人会发现”换成流水线自己就能判断的信号：在明确的观察窗口内、对照服务水平目标测得的错误率或响应时间，并配上一个已经商定的动作。演练一次回滚，好让你们知道它需要多长时间。然后把图和运行手册放在一起分享，取得图中具名人员的签署确认，只保留一个当前版本，并在任何一次出了问题的部署之后复盘它。
常见问题
部署流程和发布流程有什么区别？
发布流程决定交付什么、以及是否应该交付：哪些变更在范围之内、范围何时冻结、由谁签署 UAT 验收，以及放行与否的判断是不是“放行”。部署流程则是它底下的机制：只构建一次制品、给它打上版本号、提升它、在预发布环境验证它、把它送到生产环境的基础设施上，并在它表现异常时回滚。两者不是一一对应的。一次发布可以包含多次部署，而大量部署根本不挂在任何一次发布之下——例如代码在功能开关后面上线、稍后才被打开。这份模板讲的是机制；如果你们需要的是范围冻结、UAT 验收和放行与否的关口，请改用软件发布流程模板。
软件部署流程分为哪些阶段？
五个阶段能覆盖多数团队。构建与版本：合并变更，从干净的检出开始只构建一次制品，并把它标上所属的提交。测试与质量门：运行自动化测试与扫描，把失败退回给开发人员，而不是让它继续往前。预发布环境：把制品提升到制品库，部署到预发布环境，并对它运行冒烟测试与集成测试。审批与窗口：申请生产环境变更窗口并让部署获批，或者把它推迟到下一个窗口。生产环境上线：以蓝绿部署或灰度发布的方式部署，结合健康检查分步切换流量，一旦超出错误预算就自动回滚，否则就完成上线、持续监控，并关闭部署记录。
我们应该用蓝绿部署还是灰度发布？
蓝绿部署运行两套生产环境并在它们之间切换流量，因此上一个版本会保持热态，切回去几乎是瞬时的。代价是部署期间大约需要双倍的容量，而且所有用户都在切换的那一刻一起被切过去，于是一个只在真实流量下才会显形的问题，会一次性击中所有人。灰度发布先把一小部分真实流量送到新版本，能暴露合成测试抓不到的问题，但它需要流量调度和可以按版本切分的监控指标，耗时更长，而且它是明知故犯地让一部分用户去接触一个你们还没有把握的版本。两者都解决不了数据库变更：它们都假定上一个版本仍然能在当前的数据库结构上运行，因此迁移通常会被拆成扩展与收缩两步，分别部署。
部署应该在什么时候自动回滚？
当一个流水线自己就能判断的信号越过了商定的阈值时——而不是当有人去解读一块仪表盘的时候。在实际操作中，这意味着在明确的观察窗口内、对照服务水平目标测得的错误率、响应时间或某项具名的业务事务，一旦错误预算的消耗比商定的上限更糟，就自动暂停或撤销这次上线。有两件事让它真的管用。第一，演练回滚，好让你们知道它确实有效、以及需要多长时间。第二，把不可逆的步骤——主要是数据库结构迁移和单向的数据变更——同代码部署分开，让部署保持可撤销，否则自动化会去尝试一次数据根本承载不了的回滚。
如果我们一天部署好几次，审批该放在哪里？
逐个审批每一次部署无法规模化，而一条人们没法遵守的流程会被绕过去。通常的答案是给通道授权、而不是给单次执行授权：把这一类部署定义为预先批准的标准变更，由流水线的关口、测试和自动回滚充当控制措施，把单独审批留给落在这个模型之外的变更——例如数据库结构迁移，或任何涉及受限环境的操作。这张图里的“部署是否获批？”决策正是坐在这个位置上，那条推迟分支也正因如此才被画出来。SOC 2（准则 CC8.1）和 ISO/IEC 27001 的变更管理控制措施这类框架，要求生产环境的变更经过授权、测试并留下文档；它们并不要求每一次部署都有人签字。一张图本身不构成证据，但它所产生的部署记录、测试结果和审批，正是评估人员要求查看的东西。