DevOps研发模式下CI/CD实践详解指南

原创

测试开发技术

修改于 2019-12-09 15:05:33

1.3K0

修改于 2019-12-09 15:05:33

文章被收录于专栏：测试开发技术

阅读全文大概需要 10分钟，更多原创干货，请关注公众号：【测试开发技术】

1. 前言

借着公司今年新组建的中台研发部东风，我作为其中的主要负责人，在研发中心主导推行DevOps研发管理模式转变及质量管理创新建设，本篇文章摘取自今年9月底，笔者在公司内部针对全体研发人员的一次DevOps培训PPT中的部分内容，涉及公司敏感信息和部分章节内容顺序已经作过处理。

相信公众号内，大部分读者此前，对DevOps没并有过多或全面的接触，为了回馈读者，因此将此次公司内训其中涉及DevOps一些核心理念和实践经验抽取出来，分享给大家。（如有不正确的，欢迎纠正）

2. 到处都在说DevOps，到底DevOps是什么？

最近几年，相信大家经常会看到DevOps这个词，也有很多专门以DevOps为主题的大型行业技术峰会。虽然DevOps最近几年才在国内公司流行，但实际上DevOps早在2009 年就已经被提出来了。

那经常一直说DevOps，DevOps到底是个什么东西？

DevOps目前其实并没有一个权威的定义，即便一些在DevOps领域耕耘很久的大师，对DevOps也无法给出一个统一的定义，久而久之，行业也有这样的一个说法：“如果有1000个人在说DevOps，那DevOps可能就有一千种意思。”

Anyway，无论有多少种意思，但我想说的是DevOps它最根本的那个意思是基本上类似的。

2.1 聊一聊DevOps组成

看到上面这张图，可能有人就会说DevOps是不是Dev+Ops。

单纯从字面上来理解，DevOps 是Dev（开发人员）+Ops（运维人员），虽然名字来源于开发和运维的缩写，但DevOps并不是简单的就是开发加运维。

DevOps 所涵盖的角色范围会更广：除了开发、测试、运维还会涉及到项目经理、产品经理，甚至和销售、市场等各个部门，跨职能部门互相合作，完成某一项目或任务。

2.2 DevOps不是什么

在帮助大家理解 DevOps 到底是什么之前，先说说 DevOps 不是什么，很多人对 DevOps 可能存在一些误解：

误解一：DevOps不是一种工具，有人可能会说我在用Docker又或Jenkins等工具，是不是就表明在做DevOps了？然而这些并不意味着就在做DevOps的事情。

误解二：DevOps不是一个新角色或者说是一个新的职位， 虽然说国内确实有些公司有单独的职位是DevOps工程师，但并不代表，DevOps是一个职位，严格来说它是一类工程师的统称。

误解三：还有人说，DevOps出来之后，是不是由一个独立的团队去做所有事情，从开发到运维，一个部门就都干掉。

其实上面这几点都没有错，但对于DevOps这个概念而言，太过于狭隘了，不是简单的说DevOps就是开发加运维，DevOps是由一个团队或者由开发加运维就能搞定的。

实际上DevOps从需求到设计到开发、到测试到运维，甚至是线上的运营反馈整个全生命周期的，所以它应该是一个打通多个部门协调，协作的这样的一个平台。至于工具和自动化实际上只是DevOps实现的一种手段。或者说DevOps是通过工具，自动化，来达到这种通过工具链与持续集成、交付、反馈、优化进行端到端整合，完成无缝的跨团队、跨系统协作。

3. DevOps包含一系列工具链、平台

DevOps实践涉及到开发部门以及软件研发的整个生命周期，这意味着在整个开发生命周期中，涉及到一大批新旧工具，包括从规划、编码、测试、发布、监控等自动化的流程工具。

3.1 DevOps包含了一系列工具链

DevOps融合了一系列基本原则和实践的方法论，并从这些实践中派生出了各种工具。这些工具体现在软件开发和交付过程的不同阶段：

编码：代码开发和审阅，版本控制工具、代码合并工具
构建：持续集成工具、构建状态统计工具
测试：通过测试和结果确定绩效的工具
打包：成品仓库、应用程序部署前暂存
发布：变更管理、发布审批、发布自动化
配置：基础架构配置和部署，基础架构即代码工具
监控：应用程序性能监视、最终用户体验

3.2 国内主流的三大DevOps管理平台

除了上面说的这些工具链以外，也有一些DevOps管理平台服务，国内比较出名的就三个。

云效
TAPD
灵雀云

其中云效和TAPD属于SaaS类平台，灵雀云是基于容器技术，以DevOps为理念，面向微服务应用的新一代PaaS平台。

3.3 对DevOps工具链、平台存在的误区

好的工具、平台可以对DevOps的实施提供出非常强有力的支持，但并不代表，实施DevOps，就一定需要重新去引入或购买一堆工具、平台。

问题的关键在于：如何解决问题，而不是具体应用哪一款的工具、平台。如果组织仅仅是购买工具而不改变工作流程，这样不会改变任何事情。

4. DevOps成功的关键：组织文化的转变

DevOps 成功的关键在于文化转变，除了上面提到的工具，组织文化的转变也同等重要，我们总结出了很多 DevOps 的其他因素，比如人（People）的思想和思考方式、开发和运维的流程（Process）、精益（Lean）、自动化（Automation）、测量（Measurement。

在组织文化方面，DevOps 推崇：

尊重（Respect）
正视失败（Healthy attitude about failure）
不埋怨（Avoiding Blame）
精益求精
工程质量文化
快速验证文化
客户导向文化

5. 重新定义DevOps

到此你大概能对DevOps有一个概要的认识和理解，DevOps它是由一些规范方法，自动化实践，合作文化等在组织内部不断演进修复而产生的一种提升软件工程发布质量和效率的方法和实践。

总结为三点：

DevOps 理念：以客户、业务需求为导向，向着同一个目标前进，强调多个部门紧密沟通与协作的软件交付过程。它包括产品管理，软件开发及运营等各个方面。
DevOps核心实践：人员协作文化+持续交付能力支撑
DevOps目标是建立一种精诚合作的文化和环境，通过工具链与持续集成、交付、反馈、优化来实现跨团队、跨系统协作方式。

6. 实践DevOps需要建立哪些能力

6.1 能力一：DevOps不可或缺的自动化能力

自动化是DevOps底线！！！如果软件系统没有一套较完善的自动化测试体系，就请不要谈DevOps，要想同时提升发布效率和产品稳定性，以自动化替代手工方式快速、频繁的对软件质量进行验证是首要的手段。

主要体现在三点上：

自动化比手动快。
工具不会像人一样容易犯错误。
通过自动化按照定义执行确保每次执行的一致性。

6.2 能力二：建立持续交付能力

实现DevOps，需要给产品交付团队提供一个软件持续交付平台或者能持续交付的部署流水线，让软件从代码提交构建到交付给用户的整个过程都能自动在流水线上完成。

主要体现在三点上：

通过统一的部署流水线将从代码提交到交付给用户的整个过程高度可视化出来，信息透明；让开发、测试和运维以高度一致的方式工作在同一个流水线上，真正建立起协作。
每一次的软件变更在这个完整的流水线中得到充分的验证，尽早发现有缺陷的变更。
将一些必不可少的控制环节內建到自动化过程中，比如质量保障过程、过程度量、过程审计信息等，从而弱化很多传统依靠人为检查的管理流程。

6.3 能力三：利益共同利的合作文化

以提高业务响应效率出发，要有一荣俱荣，精诚合作，共同进步的工作态度。

7. 实践DevOps应该如何实施

DevOps所涉及的内容是非常广的，根据不同的公司现状的不同，实施落地的方式也会有所不一样。

不要盲目的去追从DevOps，不是因为大家都做，所以我也要做，需要具备更高的全局观，从瓶颈点开始着手。

应该出于解决某个业务问题的角度出发，知道要解决什么样的问题，这是非常非常重要的。如果你的交付质量和交付效率在自身企业内觉得没有问题，如果你们觉得没有问题，想想平时升级发版加班的苦逼。

当你用一些实践来解决一些业务中的实际问题，将他们串联起来，并且形成以管道式的发布流水线后，你会发现，其实你已经开始在做DevOps了。

8. DevOps转型的实践手段

8.1 实践一：以小批量的方式工作（开发、架构、组织文化的演进）

以小批量、持续的方式进行，通过反复实验、根据反馈循环快速学习，找到最正确的实施路径。这样需要把大的问题拆成一系列小的问题逐个、渐进式解决。

8.2 实践二：创建反馈循环

在小批量工作的基础上，我们要建立起反馈循环。反馈循环让我们能够持续学习，基于学习进行持续改进，持续交付流水线就是反馈循环的具体实现。

9.实践DevOps最佳实践手段：CI/CD

相信大部分读者对DevOps和CI/CD经常会弄混淆，那么如何来理解DevOps和CI/CD之间的关系呢？可以这样来理解：DevOps是CI/CD思想的延伸，CI/CD则是DevOps的技术核心，如果没有CI/CD，没有自动化测试，DevOps是没有任何意义的。所以说DevOps是以CI/CD为基础来优化程序的开发、测试、运维等各个不同环节。

9.1 CI：持续集成

持续集成是一种开发实践，它倡导团队成员需要频繁的集成他们的工作，每次集成都通过自动化构建（包括编译、构建、自动化测试）来验证，从而尽快地发现集成中的错误。让正在开发的软件始终处于可工作状态，让产品可以快速迭代，同时还能保持高质量。

9.2 什么是CD？

谈到CD，其中是包含了两层内容：持续交付和持续部署。

有时候很多人会把持续交付误认为成持续部署，然而两者是两个不同层次的能力。

持续交付：

持续交付是持续集成的延伸或者看作持续集成的下一步，它将集成后的代码部署到类生产环境，确保可以以可持续的方式快速向客户发布新的更改。如果代码没有问题，可以继续手工部署到生产环境中。它强调的是，不管怎么更新，软件是随时随地可以交付的。

持续部署：

持续部署是持续交付的下一步，在持续交付的基础上，由开发人员或运维人员自助式的定期向生产环境部署稳定的构建版本，持续部署的目标是代码在任何时刻都是可部署的，并可自动进入到生产环境。

说到这里，相信大部人已经能清楚明白了，持续交付是指团队确保每个变更可以部署至生产环境，但也许并不需要实际部署，这通常可能是出于业务方面的原因。而持续部署是指每个变更可以自动部署到生产环境。只有成功实现持续交付的前提下，才能进行持续部署。

10.DevOps提倡的原则

DevOps持续交付的八大原则对可运维性给出了这样的定义，在企业中研发和运维体系必然需要相互配合，开发团队负责功能性需求实现的同时，在架构和编码上注重非功能性需求的实现，测试团队与运维团队将围绕着各自职能的需求，规划与建设DevOps流水线中对应的工具系统，加速企业IT价值链的流转，以为企业创造更大的商业价值。