读书笔记: 持续交付
https://book.douban.com/people/fleure/annotation/6862062/
变更管理
<原文开始>手工测试环境、试运行环境和生产环境总是在严格的访问控制之下，以便确保只能通过组织制定的变更管理流程对它们进行修改。这看上去是不必要的官僚作风，但是实际研究表明，使用这种做法的组织中，其 MTBF 和 MTTR 更短。</原文结束>
## 如何使用这个成熟度模型
<原文开始>选择一个领域集中发力，该领域是你的薄弱环节，你的痛点所在。价值流分析方法会帮你识别在组织中对哪个领域进行改进最有意义。</原文结束>
<原文开始>先选择组织中真正感到痛苦的那部分人，这些人会有强烈的动机去实施这种变革，而你将会看到最大的变化。</原文结束>
<原文开始>一旦发生了变化，使用之前创建的验收条件来衡量这些变化是否达到了预期的效果。组织中的所有干系人和参与者开一个回顾会议</原文结束>
<原文开始>重复上述步骤，积累知识。做增量式的改进，并将它推广到整个组织中。</原文结束>
## 持续交付管理
<原文开始>企业治理更专注于符合度（conformance），即遵从性、保障、监管、责任和透明管理，而业务治理（business governance）更专注业务和价值创造的执行度。</原文结束>
<原文开始>尽管在业务方面，每个人最终都是为了一个共同的目标，但在执行度和符合度方面经常会成为相互冲突的力量。</原文结束>
## 主干开发
<原文开始>一直向主干提交代码，并且至少每天一次。</原文结束>
## 如何将代码库分成多个组件
<原文开始>我们并不建议让每个团队各自负责一个独立的组件。因为在大多数情况下，需求不会按照组件的边界来分。根据我们的经验，那些有能力开发端到端功能的跨功能团队更加高效。尽管一个团队负责一个组件看上去好像更高效，但事实并非如此。</原文结束>
<原文开始>首先，常常很难只修改一个单独的组件就能实现和测试某个需求，因为通常实现一个功能需要修改多个组件。如果你按组件划分团队的话，就需要两个或以上的团队合作才能完成一个功能，自然会增加更多且非必要的沟通成本。而且，在围绕组件组成的团队中，大家倾向于形成“筒仓”（silo），并进行局部优化，从而失去全局观点出发来评判项目的最佳利益的能力。</原文结束>
<原文开始>最好划分多个团队，以便每个团队都可以拿到一系列的用户故事。为了完成这些需求，每个团队都可以修改任何组件的代码。一个团队为了实现某个业务特性可以自由修改任何组件是一种更高效的工作方式。依据功能领域而不是组件来组建团队确保了每个人都有权力修改代码库的任何部分，同时在团队之间定期交换人员，确保团队之间有良好的沟通。</原文结束>
## 金丝雀发布
<原文开始>在生产环境中保留尽可能少的版本也是非常重要的，最好限制在两个版本之内。支持多个版本是非常痛苦的，所以要将金丝雀的数目减少到最低限度。</原文结束>
## 非功能需求的测试
<原文开始>很多非功能需求的横切本质（crosscutting nature）意味着，很难管理它们给项目中带来的风险。结果，这也经常导致两种不恰当的做法：从项目一开始就没有足够注意它们，或者是另一个极端，预防性架构和过分设计。</原文结束>
<原文开始>技术人员常常被其诱惑，倾向于完整、封闭的解决方案，即把自己能够想到的所有用例全部自动化。... 比如，运维人员希望不用关闭系统就可以重新部署或重新配置，而开发人员希望一劳永逸，无论是否有人提出过这样的需求，都要考虑应用程序在未来可能发生的任意一种演进。</原文结束>
<原文开始>作为技术人员，我们必须警惕自己更倾向于首先出现在脑海中的那种技术解决方案。我们必须和客户及用户紧密合作，共同确定应用程序中的敏感问题，并根据真实的业务价值定义详细的功能需求。</原文结束>
## 非功能需求的测试
<原文开始>“吞吐量” 是系统在一定时间内处理事务的数量，通常它受限于系统中的某个瓶颈。在一定工作负载下，当每个单独请求的响应时间维持在可接受的范围内时，该系统所能承担的最大吞吐量被称为它的 "容量"。</原文结束>
## 确保验收测试一直处于通过状态
<原文开始>当快要发布时，你会试图让验收测试通过，以便使你自己对软件质量感到一些自信。然而看过一遍验收测试后，你会发现，很难确定哪些验收测试是因为测试条件的变化而失败的，哪些测试是由于测试与代码紧耦合，而该代码被重构才导致的失败，或者真的是由于应用程序的行为不正确而导致的失败。</原文结束>
<原文开始>尽早修复失败的验收测试是至关重要的，否则测试套件就没有贡献真正的价值。</原文结束>
## 实现验收测试
<原文开始>首先，要抵制使用生产数据的备份作为验收测试的测试数据库的诱惑。相反，我们要维护一个受控的数据最小集。如果想在测试环境中跟踪生产系统的状态，你花在让该数据能够运行起来的时间远远要多于用它来真正做测试的时间。毕竟测试的关注点在于系统的行为，而非数据本身。</原文结束>
<原文开始>验收测试最有效的方法是：利用应用程序自身的功能来隔离测试的范围。</原文结束>
## 测试替身
<原文开始>mock 是一种被格外滥用的测试替身。人们很容易错误地使用 mock 写出不找边际且脆弱的测试，因为大家很容易通过它们来判断代码的具体工作细节而不是代码与其协作者的交互动作。这样的做法使测试很脆弱，因为假如实现细节变了，测试就会失败。</原文结束>
## 业务导向且支持开发过程的测试
<原文开始>我们倾向于将自动化验收测试限于完全覆盖 happy path 的行为，并仅覆盖其他一些极其重要的部分。</原文结束>
<原文开始>一个好的自动化测试套件应该给你足够的信心执行重构，甚至对应用程序架构进行重构。</原文结束>
<原文开始>你需要监控到底花了多长时间做重复性的手工测试，以便决定什么时候把它自动化。一个很好的经验法则就是，一旦对同一个测试重复做过多次手工操作，并且你确信不会花太多时间来维护这个测试时，就把它自动化。</原文结束>
## 测试的分类
<原文开始>他根据两个维度对测试进行了分类。一个维度是根据它是业务导向，还是技术导向。另一个维度是依据它是为了支持开发过程，还是为了对项目进行评价。</原文结束>
## 应用程序的配置管理
<原文开始>在不同环境之间管理配置信息的一种方法是，把预期的生产环境中的配置信息作为默认配置，而在其他环境中，通过适当的方式覆盖这些默认值（确保你有预防措施，以防生产环境受到配置失误的影响）。也就是说，尽量减少配置项，最好只保留那些与应用软件具体运行环境密切相关的配置项。</原文结束>
<原文开始>与应用程序一样，配置设置也需要测试。对于系统配置测试来说，包括以下两个部分。
一是要保证配置设置中对外部服务的引用是良好的。
二是当应用程序一旦安装好，就要在其上运行一些冒烟测试，以验证它运行正常。
</原文结束>
## 持续改进
<原文开始>整个团队应该定期地坐在一起，召开回顾会议，反思一下在过去一段时间里哪些方面做的比较好，应该继续保持，哪些方面做的不太好，需要改进，并讨论一下如何改进。每个改进点都应该有一个人负责跟踪，确保相应的改进活动能够被执行。当下一次团队坐在一起时，他们应该向大家汇报这些活动的结果。这就是众所周知的戴明环：计划、执行、检查、处理。</原文结束>
<原文开始>关键在于组织中的每个人都要参与到这个过程中。如果只在自己所在角色的内部进行反馈循环，而不是在整个团队范围内进行的话，就必将产生一种“顽疾”：以整体优化为代价的局部优化，最终导致相互指责。</原文结束>
## 软件交付问题
<原文开始>部署流水线的目标有三个。首先，它让软件构建、部署、测试和发布过程对所有人可见，促进了合作。其次，它改善了反馈，以便在整个过程中，我们能够更早地发现并解决问题。最后，它使团队能够通过一个完全自动化的过程在任意环境上部署和发布软件的任意版本。</原文结束>