需发布可以有效缩短变更前置时间，提高部署频率，进而产生强有力的业务影响，同时也是《The 2019 accelerate state of devops elite performance productivity and scaling》中推荐的提高软件交付效能的实践之一。精英效能组织已将按需发布作为一项基础能力，例如: CapitalOne 每天部署50次，或者例如Amazon、Google以及Netflix每天部署几千次。尽早的将业务推向市场，不仅可以抢占先机，也可以充分发挥调研的价值。
本文中的DevOps持续交付流水线平台项目，已经经过3年多的持续演进，功能逐步完善，当前平台为1000多个团队提供状态可视化和即时反馈。团队希望借助按需发布，尽早推出新功能，更快的为客户带来价值。
在之前3年多的演进过程中，平台以2周为一个迭代进行交付。在一个迭代中，大部分同学进行本迭代的功能开发，小部分同学梳理新需求，为下个迭代做准备。平台以蓝绿部署策略进行上线，在上线前准备预生产环境，为QA同学提供与生产环境相似的场景进行测试。在上线中，进行环境的切换，每次切换需要10-30分钟的维护时间。这段时间内，团队需要进行数据迁移、消息迁移、切换流量等动作。这样的交付节奏持续了两年的时间，有效的保证了平台的代码质量和迭代的平稳推进。
流水线蓝绿部署示意图
动力来源
- 随着平台功能的逐步趋于稳定、用户数量逐渐增加，项目的关注点也有所转移，团队希望缩短从需求确认到上线的时间，做到按需发布；
- 恰巧公司内部也在进行研发效能的治理；
- 团队也希望借此机会，提高平台自身的软件交付效能，随后将研发效能的度量集成在工具链平台；
实践探索
借助精益思想，我们团队开始从需求确认到上线过程中，寻找所有阻碍用户的工作。希望从各个层面上消除浪费，来提升整体的价值流动效率，助力需求的顺畅交付。
首先，我们使用“影响地图”对按需发布这个目标进行分析，发现问题，并找出对应的解决方案。然后，根据这个分析结果，制定了团队的OKR（Objectives and Key Results）。
影响地图
团队OKR
为了实现按需发布，团队分别从业务侧，开发侧和测试侧做了如下调整。
在业务侧，BA针对需求分析，做了如下调整：
1、识别可以独立交付的功能
- 除日常两周一次上线外，分析需要按需交付的功能，和团队同学（TL/QA）一起确认这些功能是否能做到独立交付；
2、迭代计划中考虑按需发布的工作量
- 为能独立交付的部分功能，拆分为单独的故事卡，打上标签，并放入迭代计划中一起考虑（主要考虑额外产生的工作量）。理想情况可以分别制定按需交付和按迭代交付两种计划，但由于目前能做到按需交付的功能有限，还不够成熟，暂时未分开；
在技术侧，团队针对现有的开发和部署策略，做了如下调整：
- Feature Branch开发：对于需要按需发布的代码，单独一个feature分支进行开发，在上线前合并到release分支，在预生产环境进行测试。上线成功后，合并回master分支。后续DevOps流水线平台也会支持一条流水线多分支自动构建，自动merge分支等功能，保证feature分支的持续集成和持续交付。
- 数据库兼容性：团队采用向后兼容的方式。对于新增表和字段等操作，可以直接增加。而对于修改，重命名等操作。团队内部也讨论一套数据库变更规则。规则如下表所示
- 预生产环境自动化准备：自动化部署脚本，一键准备预生产环境，准备时间从原来需要2位同学花费1天，缩短到1位同学2个小时。
- 部署策略：团队利用OpenShift滚动部署功能，进行应用的部署。修改原有生产环境流水线，构建镜像。完善平台的部署脚本，实现一键部署到生产环境。
- 流量异常处理：采用OpenShift的滚动部署方式，当部分旧实例关闭后，仍然在线的旧实例，将会需要承载更多的流量。设置合适maxUnavailable和maxSurge参数可以逐步的关停旧实例，以保证在线实例数量，避免部分应用瞬时流量过大。
- 服务优雅停：团队采用了优雅停的方式，避免旧实例直接停止，所带来的数据不一致的问题。
- 回滚策略：对于回滚，团队采用了与部署相似的方式，以滚动发布的方式一键回滚。
在测试侧，测试同学对于需要按需发布的功能，有了以下实践
1、需求review
- 在需求进入开发前，对其进行review和补充。着重考量需求的独立性，以及其影响范围，以此判定回归测试的范围。如果需求独立且影响范围可控，那么进一步思考测试工作的难易程度，是否容易获取稳定的测试数据，功能是否有涉及第三方依赖等。
2、功能快速验证
- 需求进入开发后，同步开发自动化测试，以便在结卡时，以部分自动化测试进行验收。测试过程中，除了进行常规测试和探索性测试，还需要上线前完成相关功能的自动化测试，用于回归。
3、依托自动化方式的回归测试
平台功能不断增加，团队就更加依赖于反馈迅速和覆盖全面的自动化测试，以快速验证按需发布的功能，并且验证原有功能不受影响。
- 反馈迅速：在自动化测试用例相互独立的前提下，利用自动化测试框架特性和流水线的并行功能，并行运行测试用例，加快自动化测试的速度，迅速获取反馈。
- 覆盖全面：在快速反馈的前提下，尽可能的提高自动化测试覆盖率。依托平台自动化测试覆盖率统计功能，根据覆盖率补充、完善自动化测试。随着业务的扩展和测试用例的增加，后续可考虑部分精准测试以提高反馈速度。
当前，流水线项目只对部分可独立交付的业务需求，做到了按需发布。平台从一个迭代发布一次，演变为一个迭代发布N次。其中N-1次是按需发布，剩余的1次为按迭代交付。对于涉及开发人数较多的，模块较大的需求，团队仍以迭代进行交付。逐步扩大按需交付的范围，也是团队今后努力的方向。
经验总结
在精益思想的指导下，团队寻找开发流程中的阻碍点，并从各个层面做出调整策略。在业务侧，分析哪些需求可以做到按需发布，哪些需要无法做到，设定适合团队的按需发布的标准，并调整迭代工作量。在开发侧，考虑数据的兼容性，部署方式，以及高频率部署所带来的环境准备问题。在测试侧，提高自动化测试的运行速度，和主流程的覆盖范围，利用自动化测试覆盖率统计功能，查缺补漏。
对于初创团队，可以将按需发布作为目标，但建议还是以正常迭代节奏进行交付，待团队成熟后再进行按需发布。
为此，可以在以下几点做准备：
- 发布流程自动化：使用Jenkins或者其他CI/CD平台搭建流水线，做到持续集成和持续交付。
- 保证无状态服务：避免实例在本地存储持久化的数据。
- 准备不停机部署策略：调研所使用发布平台的发布策略，是否支持不停机发布和回滚。
- 测试快速验证反馈：建立回归测试，项目初期搭建自动化的回归测试，优先覆盖主流程，逐渐增加测试覆盖率。
发表回复