在之前的几篇release manager阶段总结中提到了比较多的术语概念，比如：精益、敏捷、Devops、持续交付、持续部署等，这些都是软件工程领域常见的用词，然而令人头疼的是这些概念的重叠定义以及彼此之间的联系应该如何理解。那么本篇我们就来尝试解析一下这几个核心概念。
首先需要说明的是这些听起来像是哲学的概念自身有多个理解层级，比如从理念、从原则、从目标、从方法论等等。因此不同概念在不同维度理解起来彼此之间有重叠交集是正常现象。所以个人建议：不需追求完全清晰的区分开各个概念的涵盖范围，而是关注自己所理解的业务价值流，将各个概念与价值流的具体环节对应上，能够契合自己的工作开展即可。
其次，按照从抽象到具体的演进，我将这些概念组织为下图的流结构：
1. 处于最上层的是管理哲学：“精益”理念
“精益”理念来源于生产制造领域，核心思想为JIT（在需要的时间，按照需要的量，生产需要的产品）；
精益的两个主要原则： 1.坚信前置时间是最佳度量指标之一；2.坚信小批量任务交付是缩短前置时间的关键因素之一；
精益理念极大的改善了生产系统的效率和稳定性，保障了产品的质量。
2.当“精益”理念进入IT软件领域，即是“敏捷”理念
“敏捷”理念的目标是在更短的交付周期内更频繁的交付可工作的软件；
敏捷的关键举措：良好的需求管理；频繁迭代的周期sprint（建议不长于两周）；站会和看板；特性驱动测试；测试驱动开发；结对编程；开发测试团队融合；持续集成的技术手段；
敏捷保证了随时都有可以向客户展示的可工作的软件版本。
3.“敏捷”理念相对注重产品管理/开发测试沟通协作，而当它扩展到运维领域时，即是“Devops”理念
“Devops”理念的核心是协作与沟通，它希望将发布团队&运维团队与开发&测试团队融为一体，打破阻隔开发和运维的那面墙；
Devops的关键举措：自始至终所有团队为同一个目标负责，团队之间从推动式流程变为提拉式流程；
Devops更注重于组织和文化，狭义上是没有太多的技术手段。比较强相关的是“基础设施即代码”（Infra As Code），关注基础设施环境的规范管理。
4.在“敏捷”和“Devops”的基础上，再借助配置管理（版本控制等）和测试管理（自动化测试等）方法论，就形成了一种最佳实践：“持续交付”
持续交付的目标是有能力随时随地一键部署可用的软件版本到生产环境；
持续交付的关键举措是持续部署，通过一些技术手段和工具软件实现部署的自动化/无感知/可回滚等特性。
持续交付的对外呈现即是一条持续“流动”的“流水线”。
5.持续交付可被视为“Devops”的最佳实践之一，或者Devops的扩展之一。Devops还可扩展为包括持续反馈和持续改进等实践。
持续反馈：在持续交付流水线的每个阶段中应用快速的反馈机制，实现问题的快速修复，从源头控制质量。
持续改进：建立公正和学习的文化，·通过事后分析会议和故障注入来不断增强可靠性，预留专门的时间段开展组织性改进活动。
最后奉上一张简单的软件业务价值流图，后续将继续基于价值流图中的各关键环节进行学习总结：
需求 - - 开发模式 - - 变更 - - - 版本控制 - - - 环境管理 - - - 持续部署 - - - 监控反馈
| |
- - - 持续集成 - - - 自动化测试 - - -