浅谈持续交付的典型场景
范全松⾼效运维社区资深技术专家 个人介绍 范全松高效运维社区资深技术专家 1、10余年IT领域从业经验、DevOpsEnterpriseCoach2、擅长结合DevOps理论+工程实践推动企业软件交付流程优化，助力业务取得成功；对持续集成、持续交付有着深刻的理解，并且有着丰富的实战落地经验。 1 场景一：分支策略 目录 场景二：自动化测试 2 CONTENTS 场景三：分层流水线 3 场景四：度量 4 01分支策略 场景一：持续交付下的分支策略 场景一：持续交付下的分支策略 场景一：持续交付下的分支策略 关于分支策略的几点思考： •没有最好的，只有最合适的 •我们在讨论分支策略时，本质上是在讨论研发的协作模式•任何一种策略的选择，都有其自身的局限性，扬长避短 •是不是可以有跟环境绑定的分支？ •比如类似SIT分支，UAT分支等•意味着部署不同的环境，需要从对应环境的分支获取源码做编译构建 •分支策略的使用仅限于研发阶段，不应再扩散至软件交付的其他环节 •站在价值交付的角度来看，研发阶段的价值交付，是以源代码的形式，借助分支策略的使用，来收集各研发人员的价值贡献•研发团队交付出去的价值，应以制品包的形式再往后流转（Build Once，Deploy Anywhere！） 02自动化测试 场景二：持续交付下的自动化测试 人类行为总是倾向于具有高度目标性，确立一个正确的目标有着重要的心理学影响。如果我们的目的是证明程序中不存在错误，那就会在潜意识中倾向于实现这个目标，也就是说，我们会倾向于选择可能较少导致程序失效的测试案例。相反地，如果我们的目标在于证明程序中存在错误，我们设计的测试案例就有可能更多地发现问题。 软件测试的心理学测试是为发现错误而执行程序的过程 测试的不可穷尽性 正是因为测试的不可穷尽性，在绝大多数的软件工程实践中，我们不会为了绝对的质量而不计成本的投入，理性人考虑边际量（十大经济学原理之一）。通常我们会根据程序的用途和定位，制定一个合适的质量目标，在有限成本的条件下，采取某种测试策略来达到这个质量目标。 软件测试的经济学以合适的成本取得合适的质量 场景二：持续交付下的自动化测试 接口自动化测试覆盖率都100%了，为什么从来没发现过Bug？ •从术的层面，需要考虑接口自动化测试案例自身的质量•测试场景是否覆盖全面？•断言密度 •回归自动化测试本身•优势•可以替代大量的手工机械重复性操作•更好的利用无人值守时间，更频繁地执行测试•可以高效实现某些手工测试无法完成或者代价巨大的测试，比如，关键业务7*24小时持续运行的系统稳定性测试和高并发场景下的压力测试等...... •劣势 •远比手工测试脆弱•用例的开发工作量远大于单次的手工测试•自动化测试的效率很大程度上依赖于自动化测试用例的设计以及实现质量...... •适用场景 •需求稳定、不会频繁变更的场景•研发和维护周期长，需要频繁执行回归测试的场景•需要在多种平台上重复运行相同测试的场景•通过手工测试无法实现或者手工测试成本太高的测试项目•被测软件的开发较为规范并且能够保证系统可测试性的场景•测试人员已经具备一定编程能力的场景 场景二：持续交付下的自动化测试 持续交付中的自动化测试具备哪些典型特征？ 1.最早可以前置到开发阶段就能够被执行•针对历史接口或功能的回归测试，可以确保在研版本不会对线上版本功能造成破坏 2.应与流水线集成•被流水线调用执行之后其测试结果可以作为质量门禁，是建设自动化质量门禁体系的重要一环 •这是确保自动化测试结果可信度的重要基础 4.在分层测试中占据一定比例，与其他类型的测试一起组成一道道质量防护网 •不宜过度夸大自动化测试的效能•手工测试发现的缺陷数量通常比自动化测试要更多，并且自动化测试仅能发现回归测试范围的缺陷 03分层流水线 场景三：持续交付下的分层流水线 为什么需要分层流水线？ 1、从前文改良的分支策略来看：•feature分支的代码需要流水线执行哪些操作？流水线监听到feature分支有代码push事件，即触发源码编译、静态扫描（一般不需要构建制品）•develop分支的代码需要流水线执行哪些操作？流水线监听到develop分支有代码merge/push事件（此处是自动触发方式，亦可手动触发），即触发源码编译、静态扫描、构建制品及上传制品库、部署开发集成环境、调用自动化测试等•release分支的代码需要流水线执行哪些操作？流水线监听到release分支有代码merge/push事件（此处是自动触发方式，亦可手动触发），即触发源码编译、静态扫描、构建制品及上传制品库、部署开发集成环境、调用自动化测试、人工审批卡点、触发制品晋级等这些操作能够通过一条流水线集成吗？显然不能或者说效率低下——需要频繁切换拉取代码的分支以及修改流水线配置 2、从具体使用方法来看： •只做源代码的编译构建•只做发布与部署•只做提测流程及产物流转 这些单一功能的流水线，可以被一条端到端贯穿全流程的流水线所调用执行，形成主流水线下嵌套子流水线的层级结构 04度量 场景四：持续交付下的度量 度量平台建设可能存在的误区： 1.过度依赖度量指标：仅仅依赖度量指标来评估项目的成功度，而忽略了项目本身的实际情况和目标。2.忽略度量指标的可持续性：如果度量指标只适用于某个特定的时间段或情境，那么随着时间的推移，这些指标可能就不再适用。3.错误的度量方法：有时候，度量方法可能会错误地评估项目的真实情况。例如使用平均值而非方差来度量一组数据。4.过度收集数据：增加平台及相关分析人员的负担，很可能会导致错误的结论。5.缺乏反馈机制：如果缺乏反馈机制，那么度量结果就变得毫无意义。6.将度量指标作为考核指标：这将会使度量彻底变味了，大家都会倾向于把考核的度量数据做的更漂亮。7.缺乏透明度和信任：一个缺乏透明度和信任的度量平台，很容易导致项目团队对度量结果产生抵触情绪。 有 道 无 术，术 尚 可 求 也。有 术 无 道，止 于 术。 — —老 子 以 道 驭 术，术 必 成。离 道 之 术，术 必 衰。 — —庄 子 场景四：持续交付下的度量-核心路径 以围绕数据为中心的8个核心环节，开展研发数字化建设，并通过数字化评估进行逐步优化改进 场景四：持续交付下的度量-核心框架 从指标堆叠到效能提升闭环路径，行业效能度量发展的核心框架 开放运维联盟高效运维社区DevOps时代 荣誉出品
