读书笔记：《持续交付》

Posted 2022-11-21 Rolei_zl

《持续交付 . 发布可靠软件的系统方法  Continuous Delivery . Reliable Software Releases though Build, Test, and Deployment Automation》 --  Jez Humble, David Farley 著  乔梁 译

个人理解：一本挺厚的书，几乎全是文字描述，本就繁琐的操作，读起来更有些枯燥。理论与实际总是有着或多或少的差距，理论和实践是个知行合一的过程。自动化是交付实现的终极目标：无需人为干预、快速反馈、减少错误、提升效率。如何识别过程中重复的、相对稳定的过程操作，需要实践的演练，同样需要理论的支持。为什么要自动化：价值提升，通过提升效率、提高质量，提升人类活动的单位价值。

开发 -- 测试 -- 构建 -- 测试 -- 版本控制 -- 测试 -- 部署 -- 验收 -- 交付

即使是一小步一小步的进行，也会带来很大的价值
过程可见、快速反馈、自动化实现、从事更高价值活动；高效、快速、可靠，短周期、高质量；快速反馈、持续改进、降低风险，根据反馈调整行动。
质量并不等于完美，追求完美是把事情做好的大敌，交付质量足够好的软件。尽快发现错误，并消灭它们，而不是期待完美和零错误
让软件发布成为一件非常容易的事情，让所有可能的事情自动化，持续集成，快速反馈
停止依赖于大批量检查来保证质量的做法，改进过程，从一开始就将质量内嵌于产品之中。尽早识别错误，有问题就尽早失败，将流程中的痛点习量提前，让失败可视化
INVEST原则：独产Independent、可协商Negotiable、有价值Valuable、可估计Estimable、小的Small、可测试Testable
风险：流程令软件更高效的交付，同时确保风险被适当地管理，规章制定被严格遵守，迭代增量式交付
夹具，霍桑效应（由于受到额外关注而引起绩效或努力上升的情况），幂等 Idempotent、张力 tension，Happy Path，横切 crosscuting，Chicken-counting（0, 1, many，选择试应性条年），迪米特法则 Law of Demeter（LOD，最少知识原则 The Least Knowledge Principle，一个类对于其他类知道的越少越好），筒仓
金丝雀发布策略 canary release strategy：先试着将应用发布给一小撮用户群
对应用程序做的每个修改都能通过自动化构建、部署、测试过程来验证是否满足发布要求
松耦合且具有良好封闭性的协作组件，鼓励重用

软件发布应该是一个快速且可重复的过程；如何以最快的速度将软件交付给用户，体现软件价值 ；缩短从想法到商业价值实现的时间。
通过有效反馈，减少时间和降低风险；整体优化，将手工操作变成可靠、可预期、可视化的自动化过程；可靠、快速、低风险；可重复、可靠的、可预见的过程。
对问题和机会反应迅速，周转期很短使他们与其业务客户以及最终用户三方之间建立了更深层次的关系
对代码运行的环境进行良好的定义与控制，提前做麻烦的事，降低环境管理的成本和风险
快速、可靠交付有价值的软件，所有参与软件交付整个过程中的人进行更好的协作
与项目相关的所有东西都在版本控制库中：应用程序、应用程序版本、应用程序运行环境  
任何变更在上线之前都必须经过测试，持续集成的是让正在开发的软件一直处于可工作状态，确保软件在任何时候都可以工作；持续集成是一种实践，不是一个工具
有规律的尽早提交代码，有足够的时间处理可能出现的问题，保持足够的代码覆盖，保证快速反馈；将问题引入时间点到被发现时间点间隔最小化
统一度量数据的收集和监控，提供程序级的代码质量监控方式；快速反馈，尽早发现问题，降低修复成本
测试策略：识别和评估项目风险优先级，决定采用哪些行动来缓解风险
任何修改都会破坏现有功能，测试会建立我们的信心；聚焦于系统中高价值功能，保护系统当前功能，交付用户所需价值
同一测试重复做过多次手工操作，并确信不会花太多时间来维护时，就要把它自动化：当你需要做第二次时，要考虑通过自动化来完成
将易出错且复杂的步骤变成可靠且可重复的自动化过程：将会变动的和不会变动的东西分离
创建聚合报有信息、并能识别流程或代码库中问题的可视化报告
构建，环境：做什么，依赖于什么，尽可能不修改已经存在的结构
计算能力是廉价的，而人力是昂贵的
使用领域语言来实现测试
验收测试面向业务，行为驱动开发的核心理念之一就是验收测试应该以客户期望的应用程序行为的方式来书写
验收测试：可执行的验收条件、测试实现、应用程序驱动，利用应用程序自身的功能特性来隔离测试范围
测试的执行速度一定会超出应用程序的运行速度
手工测试是软件行业中的一种基准，并且常常是一个团队进行测试的唯一形式
性能：处理单一事务所花时间的一种度量；但过早且过分地关注应用程序的容量估化是低效且昂贵的
所有需求都必须给它一个值，让所有人都知道发布前做什么，不要直接对生产环境进行修改
极限编程座佑铭：如果它令你很受伤，那么就做更多的练习
大多数项目的失败原因在于人，任何变更都可能是风险，让发布有价值的软件成为一件低风险的事
要保证任何配置的修改都是以受控的方式进行的
根据测试目的创建并管理自己的最小数据集，细心选择生产数据集的最小子集
版本控制，维护应用程序每次修改的完整历史
摘樱桃 cherry-picking，从代码库上挑选一些变更发送给另一个代码库
在软件开发过程中能够对所创建和依赖的资产进行有效控制
团队磨合5阶段：创建期 forming、风暴期 storming、规范期 norming、运转期 performing、调整/重组期 mourning/reforming|
软件阶段：识别阶段 identification、启动阶段 inception、初始阶段 initiation、开发和部署阶段 development and deployment、运维阶段 operation