阅读全文大概需要 10 分钟
借着公司今年新组建的中台研发部东风，我作为其中的主要负责人，在研发中心主导推行 DevOps 研发管理模式转变及质量管理创新建设，本篇文章摘取自今年 9 月底，笔者在公司内部针对全体研发人员的一次 DevOps 培训 PPT 中的部分内容，涉及公司敏感信息和部分章节内容顺序已经作过处理。
相信公众号内，大部分读者此前，对 DevOps 没并有过多或全面的接触，为了回馈读者，因此将此次公司内训其中涉及 DevOps 一些核心理念和实践经验抽取出来，分享给大家。（如有不正确的，欢迎纠正）
最近几年，相信大家经常会看到 DevOps 这个词，也有很多专门以 DevOps 为主题的大型行业技术峰会。虽然 DevOps 最近几年才在国内公司流行，但实际上 DevOps 早在 2009 年就已经被提出来了。
那经常一直说 DevOps，DevOps 到底是个什么东西？
DevOps 目前其实并没有一个权威的定义，即便一些在 DevOps 领域耕耘很久的大师，对 DevOps 也无法给出一个统一的定义，久而久之，行业也有这样的一个说法：“如果有 1000 个人在说 DevOps，那 DevOps 可能就有一千种意思。”
Anyway，无论有多少种意思，但我想说的是DevOps 它最根本的那个意思是基本上类似的。
看到上面这张图，可能有人就会说 DevOps 是不是 Dev+Ops。
单纯从字面上来理解，DevOps 是 Dev（开发人员）+Ops（运维人员），虽然名字来源于开发和运维的缩写，但 DevOps 并不是简单的就是开发加运维。
DevOps 所涵盖的角色范围会更广：除了开发、测试、运维还会涉及到项目经理、产品经理，甚至和销售、市场等各个部门，跨职能部门互相合作，完成某一项目或任务。
在帮助大家理解 DevOps 到底是什么之前，先说说 DevOps 不是什么，很多人对 DevOps 可能存在一些误解：
误解一：DevOps 不是一种工具，有人可能会说我在用 Docker 又或 Jenkins 等工具，是不是就表明在做 DevOps 了？然而这些并不意味着就在做 DevOps 的事情。
误解二：DevOps 不是一个新角色或者说是一个新的职位， 虽然说国内确实有些公司有单独的职位是 DevOps 工程师，但并不代表，DevOps 是一个职位，严格来说它是一类工程师的统称。
误解三：还有人说，DevOps 出来之后，是不是由一个独立的团队去做所有事情，从开发到运维，一个部门就都干掉。
其实上面这几点都没有错，但对于 DevOps 这个概念而言，太过于狭隘了，不是简单的说 DevOps 就是开发加运维，DevOps 是由一个团队或者由开发加运维就能搞定的。
实际上 DevOps 从需求到设计到开发、到测试到运维，甚至是线上的运营反馈整个全生命周期的，所以它应该是一个打通多个部门协调，协作的这样的一个平台。至于工具和自动化实际上只是 DevOps 实现的一种手段。或者说 DevOps 是通过工具，自动化，来达到这种通过工具链与持续集成、交付、反馈、优化进行端到端整合，完成无缝的跨团队、跨系统协作。
DevOps 实践涉及到开发部门以及软件研发的整个生命周期，这意味着在整个开发生命周期中，涉及到一大批新旧工具，包括从规划、编码、测试、发布、监控等自动化的流程工具。
DevOps 融合了一系列基本原则和实践的方法论，并从这些实践中派生出了各种工具。这些工具体现在软件开发和交付过程的不同阶段：
除了上面说的这些工具链以外，也有一些 DevOps 管理平台服务，国内比较出名的就三个。
其中云效和 TAPD 属于 SaaS 类平台，灵雀云是基于容器技术，以 DevOps 为理念，面向微服务应用的新一代 PaaS 平台。
好的工具、平台可以对 DevOps 的实施提供出非常强有力的支持，但并不代表，实施 DevOps，就一定需要重新去引入或购买一堆工具、平台。
问题的关键在于：如何解决问题，而不是具体应用哪一款的工具、平台。如果组织仅仅是购买工具而不改变工作流程，这样不会改变任何事情。
DevOps 成功的关键在于文化转变，除了上面提到的工具，组织文化的转变也同等重要，我们总结出了很多 DevOps 的其他因素，比如人（People）的思想和思考方式、开发和运维的流程（Process）、精益（Lean）、自动化（Automation）、测量（Measurement。
在组织文化方面，DevOps 推崇：
到此你大概能对 DevOps 有一个概要的认识和理解，DevOps 它是由一些规范方法，自动化实践，合作文化等在组织内部不断演进修复而产生的一种提升软件工程发布质量和效率的方法和实践。
总结为三点：
DevOps 理念：以客户、业务需求为导向，向着同一个目标前进，强调多个部门紧密沟通与协作的软件交付过程。它包括产品管理，软件开发及运营等各个方面。
DevOps 核心实践：人员协作文化 + 持续交付能力支撑
DevOps 目标是建立一种精诚合作的文化和环境，通过工具链与持续集成、交付、反馈、优化来实现跨团队、跨系统协作方式。
自动化是 DevOps 底线！！！如果软件系统没有一套较完善的自动化测试体系，就请不要谈 DevOps，要想同时提升发布效率和产品稳定性，以自动化替代手工方式快速、频繁的对软件质量进行验证是首要的手段。
主要体现在三点上：
实现 DevOps，需要给产品交付团队提供一个软件持续交付平台或者能持续交付的部署流水线，让软件从代码提交构建到交付给用户的整个过程都能自动在流水线上完成。
主要体现在三点上：
以提高业务响应效率出发，要有一荣俱荣，精诚合作，共同进步的工作态度。
DevOps 所涉及的内容是非常广的，根据不同的公司现状的不同，实施落地的方式也会有所不一样。
不要盲目的去追从 DevOps，不是因为大家都做，所以我也要做，需要具备更高的全局观，从瓶颈点开始着手。
应该出于解决某个业务问题的角度出发，知道要解决什么样的问题，这是非常非常重要的。如果你的交付质量和交付效率在自身企业内觉得没有问题，如果你们觉得没有问题，想想平时升级发版加班的苦逼。
当你用一些实践来解决一些业务中的实际问题，将他们串联起来，并且形成以管道式的发布流水线后，你会发现，其实你已经开始在做 DevOps 了。
以小批量、持续的方式进行，通过反复实验、根据反馈循环快速学习，找到最正确的实施路径。这样需要把大的问题拆成一系列小的问题逐个、渐进式解决。
在小批量工作的基础上，我们要建立起反馈循环。反馈循环让我们能够持续学习，基于学习进行持续改进，持续交付流水线就是反馈循环的具体实现。
相信大部分读者对 DevOps 和 CI/CD 经常会弄混淆，那么如何来理解 DevOps 和 CI/CD 之间的关系呢？可以这样来理解：DevOps 是 CI/CD 思想的延伸，CI/CD 则是 DevOps 的技术核心，如果没有 CI/CD，没有自动化测试，DevOps 是没有任何意义的。所以说 DevOps 是以 CI/CD 为基础来优化程序的开发、测试、运维等各个不同环节。
持续集成是一种开发实践，它倡导团队成员需要频繁的集成他们的工作，每次集成都通过自动化构建（包括编译、构建、自动化测试）来验证，从而尽快地发现集成中的错误。让正在开发的软件始终处于可工作状态，让产品可以快速迭代，同时还能保持高质量。
谈到 CD，其中是包含了两层内容：持续交付和持续部署。
有时候很多人会把持续交付误认为成持续部署，然而两者是两个不同层次的能力。
持续交付：
持续交付是持续集成的延伸或者看作持续集成的下一步，它将集成后的代码部署到类生产环境，确保可以以可持续的方式快速向客户发布新的更改。如果代码没有问题，可以继续手工部署到生产环境中。它强调的是，不管怎么更新，软件是随时随地可以交付的。
持续部署：
持续部署是持续交付的下一步，在持续交付的基础上，由开发人员或运维人员自助式的定期向生产环境部署稳定的构建版本，持续部署的目标是代码在任何时刻都是可部署的，并可自动进入到生产环境。
说到这里，相信大部人已经能清楚明白了，持续交付是指团队确保每个变更可以部署至生产环境，但也许并不需要实际部署，这通常可能是出于业务方面的原因。而持续部署是指每个变更可以自动部署到生产环境。只有成功实现持续交付的前提下，才能进行持续部署。
DevOps 持续交付的八大原则对可运维性给出了这样的定义，在企业中研发和运维体系必然需要相互配合，开发团队负责功能性需求实现的同时，在架构和编码上注重非功能性需求的实现，测试团队与运维团队将围绕着各自职能的需求，规划与建设 DevOps 流水线中对应的工具系统，加速企业 IT 价值链的流转，以为企业创造更大的商业价值。
DevOps 提倡的原则
希望这篇文章能帮到你！如果喜欢，可以点赞或关注我们。
更多原创干货，请关注公众号：【测试开发技术】
