前言
说到一个概念，要想理解它，最好的方式的弄清楚它的本质。
举个例子：
从本质上讲，汽车和马车并没有什么不同，它们都是载人和载货的工具；再抽象一些，它们提升了人类的能力和活动范围，从本质上讲是人力的延伸。
人类所有的活动都是为了满足人类自身的某类需求，小到衣食住行，柴米油盐，大到原子探微，宇宙翱翔。
稍微回归我们的主题，软件活动也不例外：软件活动是为了满足人类某类需求而进行的活动。
随着软件活动要解决的问题越来越复杂，需要参与的人就越来越多，软件活动也变得越来越难以调和，但是不管怎么复杂，业界认可的软件活动无非包括需求活动，开发活动，测试活动和发布后的维护活动等几个活动。
对于软件活动的模型，个人觉得最好的模型是价值流模型，把软件活动做一个映射，那么有：
软件活动的目的是：
代码语言：javascript复制满足人类的某类需求 -> 交付价值软件活动包含的基本活动是：
代码语言：javascript复制需求活动，开发活动，测试活动，维护活动等 -> 价值流（的4D）用软件专业术语总结一下就是：软件活动的目的是交付价值，软件活动的过程是价值流动的过程。
价值流的4D模型
4D模型是4个D字打头的英文的组合，分别是：Discover，Define，Develop，Deploy。
翻译成中文就是：价值的发现，价值的定义，价值的开发，价值的发布。
（这个模型也有外文资料描述成5D，即在Develop之前还有一个Design，个人认为：架构设计，开发和测试均属于开发的一部分，不需要剥离出来。）
我们再把这个模型做一个更具象的表示（请关注加粗的名词）：
- 价值的发现：以客户为中心，进行需求的收集。
- 价值的定义：挖掘真实的需求，定义产品。
- 价值的开发：在项目层面，进行软件设计（架构，开发，测试，UX，etc）
- 价值的发布：发布产品，并形成反馈和闭环。
Q：为什么要花那么多篇幅和时间来描述4D模型？
A：4D模型是对软件活动的高度概括，是抽象的逻辑。无论是过去流行的理念或方法论，如：瀑布，CMMI等，还是现在流行的理念和方法论，例如：敏捷，CI，CD，DevOps等，都不会超脱这个模型。DevOps
DevOps有很多定义，不同的组织具体落地时也会各有倾向，个人认为，通过如下标签可以很清楚的描述DevOps：
- DevOps是推动价值流快速流动和健康流动的方法论，是在端到端价值传递的基础上创造价值的方法论。
- DevOps包含一套最佳实践，它同样体现了团队协作，沟通和信任的哲学和文化。
- DevOps的目标是快速高质量交付，并持续改进。
DevOps的底层支持
当我们提到DevOps的时候，往往说的是DevOps工具链。
DevOps的底层支撑是一整套完整的工具链，例如：
- 产品 - 需求管理和规划：TFS，JIRA，WIKI等等
- 产品 - 拆分到项目的开发过程：
- 代码管理和评审：Gerrit/Git，Phabricator等等
- 代码质量检查：KlocWork，Fortify，Converity, BlackDuck, Sonar等等
- 持续集成：Jenkins/Pipeline, Docker等等
- 自动化测试：RobotFramework, Postman, WebInspect, Nessus等等
- 产品 - 的发布和维护：Artifactory, Docker, Jenkins等等
常规的理解，基于这一整套工具链，形成适合产品和组织的流程乃至文化，并固化成价值观。
DevOps的进阶
做过产品的同学都知道，要想把项目做好，从来都不是仅仅有工具就足够，最根本的是要解决人的问题；所谓人的问题，并不仅仅指人的能力的问题，更重要的是人之间沟通和信任的问题。
DevOps的工具链跨越了多个领域，不同领域之间除了所从事的工作不一样之外，很容易因为认知问题和管理问题形成壁垒，也就是“墙”文化，DevOps还需要解决“墙”的问题。
DevOps的另一大法宝是把管理工作技术化，打破不同领域之间的“墙”文化。
Q：需求失真，不透明，太抽象，需求管理混乱，怎么办？ A：需求共建，需求唯一入口，需求团队决策，需求可视化。
Q：代码质量差，怎么办？ A：代码检查CI化：代码不符合（例如不符合规范，覆盖率不达标，复杂度超标等）要求直接被CI拒绝；代码评审策略化（守护评审，多人复审才能合入，等等）
Q：测试反复，测试人力不够，怎么办？ A：自动化测试，RobotFramework，Postman走起。
Q：发布版本多，发布环境不一致，没法管理，怎么办？ A：明晰的代码管理策略，分支管理策略和环境管理策略，并使之自动化。
Q：端到端的节点，数据那么多，看不过来，怎么办？ A：可视化一切流程。
DevOps误区
误区一：DevOps就是工具链
工具链只是DevOps的外在承载，其背后需要强大的管理支撑和技术支撑。
- 管理支撑达不到或者管理者意识不够强，DevOps就会沦为开发工具和测试工具，DevOps的效果最多在团队级，达不到项目级，更谈不上组织级。
- 技术支撑达不到（例如：技术能力有限），DevOps走起来会很慢，出现瓶颈，但技术能力只是时间问题，如果时间允许，终归是可以解决的。
- 管理支撑和技术支撑还需要协同才能保证最优效果：发版需要强大明晰清楚的版本管理（管理）和分支策略（技术），快速上线需要清晰明确的规划管理（管理）和自动化测试支持（技术），等等。
误区二：DevOps不适合小型团队
DevOps是产品级的实践，跟团队大小无关。分两个方面来说：
- 只要产品和产品管理完整，小团队可以使用轻量级的工具链来支撑，用不了云级的支撑，单机版服务器也可以啊。
- 如果条件不允许的话，也可以在局部领域（比如开发效率高，测试效率高）做到极致，从而推动产品进步。
后记
其实说到底，做产品、搞事情无非是要解决Why，What和How的问题，DevOps不仅仅支撑了Why，What和How，而且通过一整套自动化的工具链，加速了其进程，从而达到快速高质量交付，并持续改进的目标。
PS：DevOps和Agile
代码语言：javascript复制如果说Agile是心法的话，那么DevOps则是剑法。- Agile描述了一套价值观，却没有显式的把方法论体系化。
- DevOps定义了一套方法论，却把价值观蕴含在其实践中。
