敏捷、持续集成、持续交付

敏捷

2001年2月11日至13日，在美国雪鸟滑雪胜地，17位软件大师聚到一起，讨论了各自提出的那些轻量级软件开发方法的异同点，希望总结出它们的共性，以及与重量级瀑布方法的不同之处。参会者们包括来自极限编程、scrum、动态软件开发方法、自适应软件方法、水晶系列方法、特性驱动开发、实效编程的代表们，还包括希望找到“文档驱动、重型软件开发过程”替代品的一些推动者。会议的最终成果就是《敏捷软件开发宣言》。同时还总结了敏捷软件开发方法的十二原则，它们包括：
1、尽早地持续交付有价值的软件，以便让客户满意，这是优先级最高的事情
2、即便在开发阶段后期，也欢迎需求变化。为了让客户获得业务竞争优势，利用敏捷来应对变化
3、频繁交付可工作的软件，建议采用较短的交付周期
4、在整个项目过程中，业务人员和开发人员能够一起工作一段时间
5、围绕积极的个体，建立项目团队。给他们需要的环境和支持，并相信他们能够完成工作
6、无论团队内外，传递信息效果最好和效率最高的方式是面对面交谈
7、可工作的软件是项目进度的首要衡量标准
8、敏捷过程促进可持续发展。项目主要干系人、开发人员和用户应该能一直保持节奏
9、持续关注技术卓越和良好的设计，提高敏捷性
10、以简洁为本，它是极力减少不必要工作量的艺术
11、最好的架构、需求和设计会从自组织团队中涌现
12、团队要定期的反思“如何变得更有成效？”然后相应地调整自身行为

敏捷价值观：
个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划​

敏捷软件开发方法不是一种体系完整的方法论，而是满足上述宣言及原则的一簇轻量级软件开发方法的集合

持续集成（CI）

持续集成作为敏捷开发方法中的一个工程实践，率先被更广泛的IT组织所接受，即使那些没采纳敏捷开发方法的团队也会使用它，因为其强调的频繁自动化构建和自动化测试减少了质量保障团队的重复工作，也排出了开发团队与质量保障团队之间的沟通障碍。

CI场景起源于开发人员向代码库提交源码，CI场景中的步骤通常是这样的：
1、首先一名开发者向版本控制库提交代码。同时集成构建计算机上的CI服务器正在轮训检查版本控制库中的变更
2、在提交发生之后，CI服务器检测到版本控制库中发生了变更，所以CI服务器会从库中取得最新的代码副本，执行构建脚本，该脚本将对软件进行集成
3、CI服务器向指定的项目成员发出电子邮件，提供构建结果的反馈信息
4、CI服务器继续轮训版本控制库中的变更

CI的特征

• 与版本控制系统的连接
  版本控制库的目的是通过一个受控的访问库来管理源代码和其他软件资产的变更。为开发者提供了一个“单一源码位置”，这样所有的代码都可以从一个权威位置得到，还可以沿着时间回溯，取得源代码和其他文件的不同版本
• 构建脚本
  构建脚本是一段简单的脚本或一组脚本，可以利用它来编译、测试、审查和部署软件
• 某种类型的反馈机制
  CI的一个关键目标就是要提供集成构建的反馈信息
• 集成源代码变更的过程（手工或CI服务器）

CI的价值

• 减少风险

  缺陷的检测和修复变得更快
  软件健康程度可以测量：通过在自动集成过程中包含持续的测试和审查，这些软件产品的健康属性如复杂度等可以随时追踪

• 减少重复过程

  减少重复劳动的过程，让人们有时间做更高价值的工作；
  通过对一些重要过程自动化，克服项目中某些成员对实现改进的抵制

• 在任何时间、任何地点生成可部署的软件
• 增强项目的可见性

  有效的决策：CI系统可以对当前的构建状态和品质指标提供及时的信息，或者对缺陷率和功能完成情况的统计
  注意到趋势：CI系统经常进行集成，我们就能够注意到一些趋势，例如构建成功或失败，总体品质以及其他相关的项目信息

持续交付（CD）

DevOps运动

DevOps的萌芽源于2008年8月敏捷大会多伦多站的一个临时话题“敏捷基础设施”。当时比利时独立IT咨询师Partrick Debois非常感兴趣，并且分享了关于“将敏捷实践应用于运维领域”。2009年10月，Patrick在比利时的根特组织了一个“DevOpsDays”社区会议，并正式启用了“DevOps”这个术语。

DevOps在维基百科的定义为：DevOps是一组软件开发实践，它结合了软件开发（dev）和信息技术操作（ops），以缩短系统开发生命周期，同时根据业务目标频繁地交付特性、修复和更新。

DevOps并非一个标准、一种模式或者一套固定的方法，而是一种IT组织管理的发展趋势，也就是说，通过多种方式打破IT职能部门之间的隔阂，改变IT组织内部管理的发展趋势，使之更紧密结合，从而促进业务迭代速度更快。这种发展趋势将会引起IT组织内部原有角色与分工的变化，甚至范围更大，会影响到相关的业务组织。对互联网公司来说，其软件产品对业务发展起到极其关键的作用，业务结果与IT效能强相关，因此顺应这一发展趋势的动力更加明显和迫切。

持续交付1.0

2006年，Jez Humble、Chris Read和Dan North共同发表了一篇题为“the Development Production Line”的文章，文中讨论了软件部署带来的生产效率问题，并首次提出“部署生产线”模式。如何使自动化部署活动更轻松有以下4条基本原则：
1、每个构建阶段都应该交付可工作的软件，即对于中间产物的形成（例如搭建软件框架）不应该是一个单独的阶段
2、用同一个制品向不同类型的环境部署，即将其与运行时配置分开管理
3、自动化测试和部署，即根据测试目的，分成几个单独的质量关卡
4、这个部署生产线设计也应该随着应用程序的发展而不断演进

持续交付1.0提供的很多原则及方法是DevOps运动的具体实操指引，它们可以为企业的IT团队将DevOps运动落地实施提供非常具体的指导。

从所涉及的角色来看，敏捷开发更多地涉及产品需求方、软件开发工程师、和软件测试工程师。DevOps更多地涉及软件研发团队（开发、测试工程师）与运维工程师，而持续交付1.0涉及产品需求方、软件研发团队和运维工程师。

持续交付2.0

精益思想

持续交付1.0关注从提交代码到产品发布的过程，并且提供了一系列工作原则和优秀的实践方法，可以提高软件开发活动的效率。但在实际场景中，一些软件功能在开发完成之后，对用户或者业务来说，并没有产生什么影响，有些功能根本没有用户来使用。这些功能可能花费了团队的很多精力才设计实现，这是一种巨大的浪费，这种无用的功能生产得越多，浪费就越大。

1996年Womack、Jones和Roos在《精益思想》中指出，精益思想是指导企业根据用户需求，定义企业生产价值，按照价值流来组织生产活动，使价值在生产活动之间流动起来，由需求拉动产品的生产，从而识别整个生产过程中不经意的浪费，并消除之。

2011年出版的《精益创业》其核心思想是，开发新产品时，先做出一个简单的原型——最小化可行产品，这个原型的目标并不是马上生产出一个完美的产品，而是为了验证自己心中的商业假设。得到用户的真实反馈后，从每次试验的结果中学习，再快速迭代，持续修正，在资源耗尽前从迷雾中找到通往成功的道路，最终适应市场的需求。

在精益管理理论中，浪费是指从客户角度出发，对优质产品与良好服务不增加价值的生产活动或管理流程。在归为浪费的活动中又包括必要的非增值活动，如质量检查，和纯粹的浪费，如因质量问题导致的返工。

双环模型

持续交付2.0是一种产品研发管理思维框架。它将精益创业与持续交付1.0结合起来，强调业务与研发之间的快速闭环，以精益思想为指导，贯彻“识别和消除一切浪费”的理念，通过一系列工作原则与实现，帮助企业以一种可持续方式高质量、低成本、无风险地快速交付客户价值。
持续交付2.0是一个从业务问题出发，到业务问题解决的完整业务闭环，它由两个相连的环组成：第一个环为探索环，其主要目标是识别和定义业务问题，并制定出最小可行解决方案进入第二个环；第二个环为验证环，其主要目标是以最快速度交付最小可行方案，可靠地收集真实反馈，并分析和验证业务问题的解决效果，以便决定下一步行动。

持续交付的4个核心原则：
1、坚持少做
无论公司实力如何，想做的事情永远超过自己的交付能力，需求永远做不完。我们应该抵住“通过大量计划来构建最佳功能”的诱惑，坚持少做，想办法对新创意尽早验证
2、持续分解问题
企业应该坚信，即便是很大的课题或者大范围的变更，也可以将其分解为一系列小的变更，快速解决，并得到反馈，从而尽早消除风险
3、坚持快速反馈
当把问题分解以后，如果我们只是一味地埋头苦干而忽视对每项已完成工作的反馈结果，那么就失去了由问题分解带来的另一半收益，确认风险解除或降低。只有通过快速反馈，我们才能尽早了解所完成工作的质量和效果
4、坚持改进并衡量
在着手解决每个问题之前，我们都要找到适当的衡量方式，并将其与对应的功能需求放在同等重要的位置上，一起完成