共计 2805 个字符，预计需要花费 8 分钟才能阅读完成。
微服务架构下，每个应用服务独立开发、独立公布，小步快跑，继续疾速交付业务需要。多人协同开发同一个利用时，分支开发模式是一个适宜的协同计划。该模式下一个需要或工作通常对应一个 feature 分支，多个需要一起合并到 release 分支进行集成测试验证并公布。期间可能遇到以下问题：
- 痛点 1：当开发同学领到一个需要时，怎么为这个需要疾速地拉一个 feature 分支？
- 痛点 2：当多个相干需要一起公布时，多个 feature 分支怎么高效自动化地合并到 release 分支？
- 痛点 3：当其中一个 feature 分支没有通过测试验证时，怎么“阻止”它公布到生产环境防止漏测引起故障？
- 痛点 4：当其中一个 feature 分支做了测试验证，然而发现有重大问题，怎么能够“退出”本次公布而不影响其余需要失常公布？
- 痛点 5：当一个需要 feature 分支提交测试了、公布上线了，怎么主动、及时的更改相应需要状态，便于相干业务、产品、测试同学跟踪进度？
云效解决方案
云效应用交付平台 AppStack 提供的变更继续交付解决方案能够比拟轻松地解决以上问题。在理解具体的应用前，咱们先理解下 AppStack 中波及的一些外围概念：
- 利用： 一个软件的最小公布单元，聚合代码、环境、版本等软件资产，以及研发流程定义。最小公布单元意味着无奈解耦的一个或者多个服务的组合，这个服务组合会通过一个流程进行对立交付。
- 变更： 变更是对利用的一次个性扭转（引入新的个性或扭转已有个性），源于需要，终于交付。通常一个需要或工作对应一个变更，对应一个 feature 分支。
- 研发流程： 利用实现一次变更的过程和束缚，包含开发、测试、公布上线的残缺流程，由多个阶段的多条流水线承载，顺次在不同环境进行测试、构建、部署，最终审批通过后公布生产环境。
上面，咱们以一个 spring-boot 利用的“图书馆管理系统”为例，演示如何在云效应用交付平台 AppStack 中开发“图书借阅性能”、“图书偿还性能”、“图书到期续借性能”三个需要，并一起公布上线。** 过程中，前述的 5 个痛点都将失去解决。
作为利用负责人
作为利用负责人，须要编排利用构建、部署流程，通过流水线工具自动化起来；须要定义利用生产公布准则，来标准利用研发流程升高公布危险。
新建利用
新建利用，输出利用名称，利用模板抉择「变更继续交付模式」。
代码源配置
利用设置，配置利用代码源，设置默认分支。
配置研发流程
本利用的研发流程能够分为测试阶段、预发阶段、生产阶段：
- 测试阶段：由 Java 单元测试、Java 代码扫描、构建、部署测试环境等步骤组成。用于日常测试验证。
- 预发阶段：由构建、部署预发环境等步骤组成。用于预公布验证。
- 生产阶段：由构建、生产公布审批（人工卡点）、部署生产环境、合并骨干、敞开变更等步骤组成。
- 生产公布审批通过后，部署生产环境。
- 生产环境部署验证通过后，表明本次公布胜利，能够将公布 release 分支合并回骨干 master，并主动敞开相干变更。
设置变更集成形式和准入规定
本示例各阶段都抉择「增加变更集成」形式，在运行阶段流水线时能够抉择多个变更分支集成到 release 分支进行构建部署验证。
- 测试阶段：无准入规定。
- 预发阶段：配置准入规定为：「测试阶段 - 执行后果」等于「胜利」，防止没有通过测试验证的分支间接进入预发。
- 生产阶段：配置准入规定为：「测试阶段 - 执行后果」等于「胜利」，「预发阶段 - 执行后果」等于「胜利」，防止没有通过预发验证的分支间接进入生产阶段。
作为一线开发
“需要 1：图书借阅性能”、“需要 2：图书偿还性能”、“需要 3：图书到期续借性能”三个需要别离调配给开发小张、小明、小强开发。
第 1 步，为一个需要新建一个变，更拉一个 feature 分支
小张创立一个变更「变更 1- 实现图书借阅性能」，抉择新建分支输出 feature001，则可主动为该需要拉取一个分支（解决上述痛点 1）。顺次类推，小明创立一个变更「变更 2- 实现图书偿还性能」，主动新建分支 feature002。小强创立一个变更「变更 3- 实现到期续借性能」，主动新建分支 feature003。
第 2 步，开发代码提交到 feature 分支
小张开发好图书借阅相干代码后，提交代码到 feature001 上，小明开发图书偿还相干代码后，提交代码到 feature002 分支上。
第 3 步，抉择变更集成，部署测试环境验证
小张和小明，一借一还，须要一起部署到测试环境进行联调验证。进入利用研发流程页，抉择变更 1 和变更 2 一起集成测试，云效会主动将 feature001 和 feature002 合并到主动生成的 release/xxx_n 分支（解决上述痛点 2），应用该 release 分支做构建，并部署环境。环境部署胜利即可进行测试验证。
第 4 步，提交变更进行预公布
测试环境验证通过，进入「预发阶段」，抉择变更 1 和变更 2 进行集成，勾选主动合并上一阶段集成的分支，会主动生成新的 release/xxx_m 集成分支，主动合并上一阶段 feature001、feature002、release/xxx_n 分支，应用新的 release/xxx_m 分支构建并部署预发环境。预发部署胜利后即可进行预发验证。
此时若在预发阶段抉择变更 1、变更 2、变更 3 一起集成，则通过变更准入卡点时会校验失败，因为变更 3 没有在测试环境部署验证过，即保障了没有通过测试验证的需要不可公布（解决上述痛点 3）。
变更 3 因没有测试验证通过，不满足公布条件，团队本次决定图书续借性能不上线，只上线变更 1 和变更 2，则可再次运行预发阶段流水线，将变更 3 踢出集成区，退出本次公布（解决上述痛点 4）。
第 5 步，提交变更进行生产公布
预发验证通过后，即可进入生成公布阶段。抉择待发布的变更 1 和变更 2，运行生产流水线，公布审批通过后，即可部署生产环境。生产环境部署实现，可配置主动敞开变更，并将公布 release/xxx_k 分支合并入主干 master，至此即实现了一次残缺的需要公布上线。
作为业务 / 产品同学
变更公布实现了，我作为产品同学怎么晓得需要公布了呢？云效 AppStack 的变更和云效我的项目我的项目合作 Projex 中的工作项做了状态联动，反对变更公布实现后主动将需要状态置为「已公布」，这样产品同学可及时看到需要停顿（解决上述痛点 5）。
具体配置形式如下：进入云效 Projex 我的项目 - 我的项目设置 - 自动化规定，抉择「反对工作项与变更状态的联动」模板，配置当产品类需要关联的全副变更状态为「已公布」时，将需要状态置为「已实现」。
至此，本计划实现了从利用配置、到需要开发、多变更集成测试、公布上线的残缺流程，满足了变更分支主动创立、变更分支主动合并集成测试、公布准入卡点管制等诉求，反对变更关联业务需要和状态联动，残缺追溯需要的全生命周期流程。
🔔 注： 云效 AppStack 中的变更继续交付模式为高级版付费性能，退出钉钉群：42574350 可申请收费试用体验。
点击此处，理解更多。
