如何理解DevOps？
近几年devops成为了软件研发交付领域的“热门选手”。
不仅在各种技术大会频频亮相，业内也有很多优秀的技术实践。
那么devops是什么呢？它有什么特点，能解决什么问题，又能为技术团队能带来什么价值？
这篇文章，我想结合自己最近学习的关于devops的知识，来谈谈我的理解。
什么是DevOps？
维基百科中对于devops是这样定义的：
DevOps（Development + Operations）是一种文化、一场运动或实践，强调在自动化软件交付流程及基础设施变更过程中，软件开发人员与其他信息技术（IT）专业人员彼此之间的协作与沟通。
它旨在建立一种文化与环境，使构建、测试、软件发布得以快速、频繁以及更加稳定地进行。
仅从字面意思很难读懂devops到底是什么，不妨选取其中的关键词来理解。
- 目标：建立一种文化与环境
- 人员：研发及其他IT专业人员
- 如何做：在自动化软件交付流程及基础设施变更过程中协作和沟通
- 期望结果：使软件的构建、测试、发布可以快速、频繁、稳定的运行
结合上面的解析和我个人的软件工程实践经验，重新来定义devops的话，我对devops的定义是：
通过建立一种研发和相关技术人员高效协作沟通的环境，利用工具支撑软件的研发测试交付和基础设施变更过程，使软件从构建到发布可以更快速、频繁的交付并且可以持续稳定运行。
DevOps解决了什么问题？
devops从字面来看，就是（Development + Operations），即开发和运维。要了解devops解决了什么问题，需要从软件工程的角度来解读。
最开始，软件从需求到上线发布，采用的流程都是瀑布模型，稍晚有了V型和W模型。
这个过程中研发、测试、运维三种角色的工作开展是上下游依赖和制约的，只有上一环节完成后，才能流转到下一阶段。
后来出现了敏捷研发的理念，它提倡是把大的目标拆解为一个个小目标，小步快跑，快速迭代快速验证。
测试左移的概念也是如此，即：将测试活动从测试阶段开始向研发阶段扩展，比如单元测试、测试参与code review和技术方案评审中。这其实相当于研发和测试之间打破了隔阂，开始了融合协作。
而在devops的文化理念和实践中，就是打破研发、测试、运维及其他技术人员之间协作的那堵墙，通过高效的协作沟通，使软件从编码构建到线上发布交付形成自动化交付流水线，更快的响应和支撑业务需求，从而创造更大的业务价值。
DevOps创造了什么价值？
早期在瀑布模型时代，前期需求调研是严谨的，开发的需求也是确定不易变的，系统的架构也没那么复杂，所以大家只需要按部就班的完成本岗位要做的事情即可，研发测试运维之间界限分明，职责明确。
近几年互联网浪潮带来的红利消耗殆尽，市场竞争越来越激烈。站在风口上猪都有可能起飞，大家都怕自己不是那头猪。这就导致了这样一个现状：业务迭代越来越快，需求确定性越来越低。
而软件系统架构越来越复杂，这就导致了每次迭代要保障软件的质量在一定水准之上所要付出的成本越来越高。
从软件工程角度来说，为了摆脱软件质量危机，要利用工程化的方法去规范软件开发，让软件开发项目可以按时保质完成的同时且成本可控。
抽象归纳就是：以软件开发为核心，对开发过程组织+对方法的运用+对工具的使用。
而devops可以说是目前软件工程领域的最佳实践。通过devops的实践带来的自动化交付流水线能力，可以在保障软件质量的同时提高过程效率，支撑业务的快速迭代，更好的保障业务目标的达成。
而业务竞争力的不断增强，又需要技术不断的升级提效。这是一个互相支撑和促进的双赢闭环模型。
所以，devops的价值就在于：
- 在保障交付质量的前提下提高软件研发交付效率；
- 高效的交付支撑了业务目标更快达成，技术和业务互相促进闭环；
- 业务目标达成更有利于企业员工自身跟着平台成长而获利和成长；
虽然说devops是目前软件工程领域的最佳实践，但软件开发过程的演进，除了依赖技术的进步，还需要不断有更先进的理念引领，需要好的流程机制来保障演进过程，需要团队成员一起认同快速交付的价值，也需要有好的工具和平台来支撑在工作中的实践。
