敏捷、持续集成、持续交付
敏捷
2001年2月11日至13日，在美国雪鸟滑雪胜地，17位软件大师聚到一块儿，讨论了各自提出的那些轻量级软件开发方法的异同点，但愿总结出它们的共性，以及与重量级瀑布方法的不一样之处。参会者们包括来自极限编程、scrum、动态软件开发方法、自适应软件方法、水晶系列方法、特性驱动开发、实效编程的表明们，还包括但愿找到“文档驱动、重型软件开发过程”替代品的一些推进者。会议的最终成果就是《敏捷软件开发宣言》。同时还总结了敏捷软件开发方法的十二原则，它们包括：
一、尽早地持续交付有价值的软件，以便让客户满意，这是优先级最高的事情
二、即使在开发阶段后期，也欢迎需求变化。为了让客户得到业务竞争优点，利用敏捷来应对变化
三、频繁交付可工做的软件，建议采用较短的交付周期
四、在整个项目过程当中，业务人员和开发人员可以一块儿工做一段时间
五、围绕积极的个体，创建项目团队。给他们须要的环境和支持，并相信他们可以完成工做
六、不管团队内外，传递信息效果最好和效率最高的方式是面对面交谈
七、可工做的软件是项目进度的首要衡量标准
八、敏捷过程促进可持续发展。项目主要干系人、开发人员和用户应该能一直保持节奏
九、持续关注技术卓越和良好的设计，提升敏捷性
十、以简洁为本，它是极力减小没必要要工做量的艺术
十一、最好的架构、需求和设计会从自组织团队中涌现
十二、团队要按期的反思“如何变得更有成效？”而后相应地调整自身行为编程
敏捷软件开发方法不是一种体系完整的方法论，而是知足上述宣言及原则的一簇轻量级软件开发方法的集合服务器
持续集成（CI）
持续集成做为敏捷开发方法中的一个工程实践，率先被更普遍的IT组织所接受，即便那些没采纳敏捷开发方法的团队也会使用它，由于其强调的频繁自动化构建和自动化测试减小了质量保障团队的重复工做，也排出了开发团队与质量保障团队之间的沟通障碍。架构
CI场景起源于开发人员向代码库提交源码，CI场景中的步骤一般是这样的：
一、首先一名开发者向版本控制库提交代码。同时集成构建计算机上的CI服务器正在轮训检查版本控制库中的变动
二、在提交发生以后，CI服务器检测到版本控制库中发生了变动，因此CI服务器会从库中取得最新的代码副本，执行构建脚本，该脚本将对软件进行集成
三、CI服务器向指定的项目成员发出电子邮件，提供构建结果的反馈信息
四、CI服务器继续轮训版本控制库中的变动框架
CI的特征
- 与版本控制系统的链接
版本控制库的目的是经过一个受控的访问库来管理源代码和其余软件资产的变动。为开发者提供了一个“单一源码位置”，这样全部的代码均可以从一个权威位置获得，还能够沿着时间回溯，取得源代码和其余文件的不一样版本 - 构建脚本
构建脚本是一段简单的脚本或一组脚本，能够利用它来编译、测试、审查和部署软件 - 某种类型的反馈机制
CI的一个关键目标就是要提供集成构建的反馈信息 - 集成源代码变动的过程（手工或CI服务器）
CI的价值
- 减小风险
缺陷的检测和修复变得更快
软件健康程度能够测量：经过在自动集成过程当中包含持续的测试和审查，这些软件产品的健康属性如复杂度等能够随时追踪运维 - 减小重复过程
减小重复劳动的过程，让人们有时间作更高价值的工做；
经过对一些重要过程自动化，克服项目中某些成员对实现改进的抵制学习 - 在任什么时候间、任何地点生成可部署的软件
- 加强项目的可见性
有效的决策：CI系统能够对当前的构建状态和品质指标提供及时的信息，或者对缺陷率和功能完成状况的统计
注意到趋势：CI系统常常进行集成，咱们就可以注意到一些趋势，例如构建成功或失败，整体品质以及其余相关的项目信息测试
持续交付（CD）
DevOps运动
DevOps的萌芽源于2008年8月敏捷大会多伦多站的一个临时话题“敏捷基础设施”。当时比利时独立IT咨询师Partrick Debois很是感兴趣，而且分享了关于“将敏捷实践应用于运维领域”。2009年10月，Patrick在比利时的根特组织了一个“DevOpsDays”社区会议，并正式启用了“DevOps”这个术语。spa
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.0提供的不少原则及方法是DevOps运动的具体实操指引，它们能够为企业的IT团队将DevOps运动落地实施提供很是具体的指导。
从所涉及的角色来看，敏捷开发更多地涉及产品需求方、软件开发工程师、和软件测试工程师。DevOps更多地涉及软件研发团队（开发、测试工程师）与运维工程师，而持续交付1.0涉及产品需求方、软件研发团队和运维工程师。
持续交付2.0
精益思想
持续交付1.0关注从提交代码到产品发布的过程，而且提供了一系列工做原则和优秀的实践方法，能够提升软件开发活动的效率。但在实际场景中，一些软件功能在开发完成以后，对用户或者业务来讲，并无产生什么影响，有些功能根本没有用户来使用。这些功能可能花费了团队的不少精力才设计实现，这是一种巨大的浪费，这种无用的功能生产得越多，浪费就越大。
1996年Womack、Jones和Roos在《精益思想》中指出，精益思想是指导企业根据用户需求，定义企业生产价值，按照价值流来组织生产活动，使价值在生产活动之间流动起来，由需求拉动产品的生产，从而识别整个生产过程当中不经意的浪费，并消除之。
2011年出版的《精益创业》其核心思想是，开发新产品时，先作出一个简单的原型——最小化可行产品，这个原型的目标并非立刻生产出一个完美的产品，而是为了验证本身心中的商业假设。获得用户的真实反馈后，从每次试验的结果中学习，再快速迭代，持续修正，在资源耗尽前从迷雾中找到通往成功的道路，最终适应市场的需求。
在精益管理理论中，浪费是指从客户角度出发，对优质产品与良好服务不增长价值的生产活动或管理流程。在归为浪费的活动中又包括必要的非增值活动，如质量检查，和纯粹的浪费，如因质量问题致使的返工。
双环模型
持续交付2.0是一种产品研发管理思惟框架。它将精益创业与持续交付1.0结合起来，强调业务与研发之间的快速闭环，以精益思想为指导，贯彻“识别和消除一切浪费”的理念，经过一系列工做原则与实现，帮助企业以一种可持续方式高质量、低成本、无风险地快速交付客户价值。
持续交付2.0是一个从业务问题出发，到业务问题解决的完整业务闭环，它由两个相连的环组成：第一个环为探索环，其主要目标是识别和定义业务问题，并制定出最小可行解决方案进入第二个环；第二个环为验证环，其主要目标是以最快速度交付最小可行方案，可靠地收集真实反馈，并分析和验证业务问题的解决效果，以便决定下一步行动。
