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