《DevOps实践指南》笔记-Part 2

一篇文章显得略长，本文对应第3-4章。前言、第1-2章请参考Part 1；第5-6章、附录、认证考试、参考资源等内容，请参考Part 3。

流动的技术实践

持续交付：降低在生产环境中部署和发布变更的风险。包括：打好自动化部署流水线的基础、确保团队能够使用自动化测试持续验证代码是否处于可部署状态、保证开发人员每天都将代码提交到主干、构建有利于实现低风险发布的环境和代码。

下面这些DevOps实践能有效缩短创建类生产环境的前置时间。持续测试可以为每个团队成员快速提供反馈，让小型团队能够安全、独立地开发、测试和向生产环境部署代码，从而使向生产环境的部署和发布成为日常工作的一部分。

为部署流水线奠定基础

为了使工作快速可靠地从开发流向运维，应当保证价值流的每个阶段都使用类生产环境。

部署流水线的目标就是能够基于VCS中的信息重复搭建整套生产环境。

在过程中保证质量，而不是事后检查质量。

这些问题可以归咎于不一致的环境和没有将变更纳入VCS。

按需搭建开发环境、测试环境和生产环境

应用统一的代码仓库

必须把下列资源也纳入版本控制系统：

• 应用的所有代码和依赖项（库、静态内容等）；
• 任何用于创建数据库模式的脚本、应用的参考数据等；
• 所有用于搭建环境的工具和工件（VMware或AMI虚拟机模板、Puppet或Chef配置模块等）；
• 任何构建容器所使用的文件（Docker、Rocket、Compose文件等）；
• 所有支持自动化测试和手动测试的脚本；
• 任何支持代码打包、部署、数据库迁移和环境置备的脚本；
• 所有项目工件（需求文档、部署过程、发布说明等）；
• 所有云平台配置文件（AWS Cloud Formation模板、Microsoft Azure Stack DSC文件，OpenStack HEAT模板文件）；
• 创建支持多种基础设施服务（企业服务总线、数据库管理系统、DNS区域文件、防火墙配置规则和其他网络设备）所需的任何其他脚本或配置信息。

使基础设施的重建更容易

运行在类生产环境里才算完成

一般来说，部署的间隔时间越长，软件质量越差。

完成指不仅实现功能正确的代码，且在每个迭代周期结束时，已经在类生产环境中集成和测试可工作和可交付的代码。

实现快速可靠的自动化测试

对代码和环境做持续构建、测试和集成

部署流水线工具：Jenkins、ThoughtWorks GoCD、Concourse、Bamboo、Microsoft Team Foundation Server、TeamCity和GitLab CI，以及基于云的解决方案，例如Travis CI和Snap。

构建快速可靠的自动化测试套件

自动化测试从快到慢分为：

• 单元测试：通常独立测试每个方法、类或函数。目的是确保代码按照开发人员的设计运行。由于诸多原因（如需要进行快速和无状态的测试），通常会使用打桩（stub out）的方式，隔离数据库和其他外部依赖（如把函数修改为返回静态的预定义值，而不是调用数据库）。
• 验收测试：通常整体测试应用，确保各个功能模块按照设计正常工作（例如符合用户故事的业务验收标准，API能正确调用），而且没有引入回归错误（即没有破坏以前正常的功能）。JezHumble和David Farley认为单元测试和验收测试的区别在于：单元测试的目的是证明应用的某一部分符合程序员的预期……验收测试的目的则是证明应用能满足客户的愿望，而不仅仅是符合程序员的预期。”在构建的版本通过单元测试后，部署流水线就对其执行验收测试。任何通过验收测试的构建版本通常都可用于手动测试（例如探索性测试、用户界面测试等）和集成测试。
• 集成测试：保证应用能与生产环境中的其他应用和服务正确地交互，而不再调用打桩的接口。Jez Humble和David Farley写道：“大部分系统集成测试工作都是在部署应用的新版本，并使它们能正常协作。在这种情况下，冒烟测试通常是指针对整个应用进行的一组成熟的验收测试。”只有通过单元测试、验收测试的版本才能执行集成测试。集成测试通常是脆弱的，应该尽量减少其次数，并且要在单元测试和验收测试期间，尽可能多地找出缺陷。一个至关重要的架构需求是，在执行验收测试时能够调用虚拟或模拟的远程服务。

尽早发现错误：最快速的测试应该尽可能多地发现错误。如果大多数错误都是在验收测试和集成测试阶段发现的，那么开发人员收到反馈的速度要比单元测试发现错误时慢上好几个数量级——集成测试需要用到稀缺且复杂的集成测试环境（每次只能供一个团队使用），因此反馈更慢。

在部署流水线失败时拉下安灯绳

并行测试：

TDD：Test Driven Development，测试驱动开发。极限编程。的
3个步骤：

• 确保测试失败，为想要增加的功能编写测试用例，检入测试用例；
• 确保测试通过，编写实现功能的代码，直到测试通过，检入代码；
• 重构新旧代码，优化结构，确保测试都能通过，再次检入代码。

ATDD：基于TDD，验收测试驱动开发，Acceptance Test Driven Development，

瀑布式Scrum反模式（w