近年来，伴随着国内数字化转型的逐渐深入，DevOps的热度不断攀升，各行各业都在进行DevOps转型建设，其在提升业务价值交付能力及推进企业从内至外的数字化进程上有着重要意义。因此，了解DevOps方法论和它的实际落地案例，便显得尤为重要。

往期DevOps干货内容请戳：

1. 解决软件交付“最后一公里”的 DevOps，你了解多少？
2. 如何为你的企业选择合适的DevOps平台
3. 企业该如何解决DevOps转型道路上的常见障碍？

本次直播我们邀请到DevOps咨询顾问王英伟老师，为大家讲述DevOps方法论和实践指导。王英伟老师曾任职于电信、自媒体、电子商务、互联网等领域的科技公司，有着丰富的开发、项目管理、DevOps实施经验。同时，老师还是中国DevOps社区核心组织者，曾参与《京东敏捷实践指南》、《敏捷无敌之DevOps时代》、《DevOps悖论》等书的翻译、审校工作。

英伟老师认为，DevOps的建设是一个长期的、持续改进的过程，需要结合企业自身实际建设平台及自动化工具，同时也要提升内部人员理论、实践能力。

 

一、需求管理模型和敏稳双态开发

在研发产品之前，我们都需要先了解客户的需求。常见的需求理论模型有三种，可基于不同业务和产品复杂度的需求层次结构进行选择。

• 简单的业务和产品：拆分成两层，产品需求➡技术任务
• 典型的业务和产品：拆分成三层，业务需求➡产品需求➡技术任务
• 复杂的业务和产品：拆分成四层，业务需求➡产品特性➡产品需求➡技术任务

那么如何将需求理论模型跟现有的流程结合起来呢？

下图为某大厂公布的研发效能白皮书中的一张图，根据需求来源的不同和不同人员所需要具备的能力，把产品管理分成三个层次，通过流程与工具相结合进行描述或使用项目管理工具。

软件开发流程在这儿不过多介绍，业界用的最多的就是瀑布开发模式、敏捷开发模式和DevOps开发模式。尽管常见的开发模式是这些，但是大多数工具只支持敏捷开发模式，很少有工具支持双态（既支持瀑布，又支持敏捷开发模式）模式。

我们对标业界最佳实践，争做国内最好的项目管理工具，不仅既支持瀑布开发模式，还支持敏捷开发模式；同时具备存储文档、Wiki等功能。也就是说，在项目管理和需求管理方面，我们的平台能涵盖95%以上的使用场景。

二、DevOps涵盖产品全生命周期

有些人可能对敏捷、DevOps等涵盖的领域有些模糊。一般来讲，敏捷解决的是业务部门和研发部门之间的矛盾，DevOps解决的是开发测试运维这一过程中可能遇到的冲突，涵盖的是整个产品全生命周期。

1. 研发环境

随着公司规模的扩大，开发层面常面临以下问题：

• 公司需要不断为企业研发人员配备合适的本地研发工具（如多核高内存的计算机设备、Mac 笔记本电脑），这些设备可能价值不菲，而且需要定期的更新换代。
• 新加入的员工，在正式开始开发前，需要配置复杂的本地开发环境，安装特定的软件及插件，并熟悉项目的研发流程及各个线上系统；部分项目因为网络配置等问题，可能第一时间无法在本地启动，还会耽误不少额外的配置及调试时间。
• 公司需要投入较多的资源，才能构建起匹配管理者需求的效能度量系统和安全管控系统，并且因为云端体系天生对开发者本地环境的弱管控性，效果只能差强人意。
• 当产品对保密性要求极高，或者当企业外部成员参与对代码保密性有要求的项目时，需要确保核心代码的安全管控。

由此可见，本地开发环境已逐步难适应因公司规模扩大所带来的问题，云端开发工具（WebIDE）应运而生。尽管云端开发工具有优势也有劣势，不同的人对它所持的态度也不同，但云端开发已是不可阻挡的趋势。

2. 代码仓库

在研发的过程中，经常会使用到代码仓库。代码仓库的开发流程通常为：开发人员下载代码➡创建工作分支➡提交代码➡创建合作请求➡邀请团队成员➡参与代码评审➡仓库管理员审视后合入代码。

开源的代码仓库通常应用架构集中，一旦待机则全部应用不可用。除此之外，开源代码仓库只能使用共享文件系统支撑，如需扩展得采用nfs，ceph等方案。不仅风险高，扩展性能也低，对硬件的要求也高。

 

3. 代码管理

为什么做要做静态代码检查？因为代码交付过程常见的问题和风险有很多，比如：

• 重复代码过多，造成开发人力的浪费以及后期维护成本增加
• 编码风格糟糕，代码凌乱、不可读，难于维护与开发修改
• 圈复杂度过高，造成代码可维护性、可继承性降低，问题定位难度加大
• 编码安全风险，使用具有安全风险的函数，导致系统的安全性层级降低，加大系统的安全风险

那么，需要检查代码的什么方面呢？以下列举几种常见的代码静态检查关注点：

重复率：表示一段源代码在一个程序，或者一个团体所维护的不同程序中重复出现

代码风格：程序开发人员所编写源代码的书写风格，良好代码风格的特点是使代码易读

圈复杂度：衡量一个模块判定结构的复杂程度，数量上表现为独立线性路径条数，圈复杂度大说明程序代码可能质量低且难于测试和维护

代码安全：编码过程中，常见的安全问题包括（但不限于）：缓冲区溢出/跨站脚本攻击(XSS)/SQL注入/XML 注入/LDAP 注入

点击阅读原文，可下载PPT查阅静态代码检查常用分析技术和代码检查的常用工具介绍

蓝鲸DevOps平台代码扫描工具CCheck当下所具备的能力项，不仅内置了检查规则，并对相关规则做了简化，便于团队人员使用，能够在较短的时间内逐步提高代码质量。

4. 测试场景

在测试领域，一直争论不休的话题有：关于单元测试到底是由开发人员来做还是测试人员来做？针对当下常用的微服务架构，契约测试和Mock测试又该如何去做？以及如果有在线测试系统的话，又该如何把在线测试系统与本地的测试工具做联动？

微服务是一种架构风格，它将单个的应用设计成一组服务的集合。微服务架构由于自身的高度模块化、可独立部署和技术多样性优势，在当前开发系统或业务系统广泛应用。

尽管微服务架构已十分普遍，但其存在着的分布式、最终一致性和管理复杂性等特性，也让过去的测试理念及工具略有些“束手无策”。

契约测试和Mock测试

微服务架构下，当一个服务已经同时被多个使用者调用的时候，怎么保证整体服务不会对其他使用者造成影响呢？契约测试，能很好的避免这类问题。

契约测试定义了一套数据标准，既包含了请求也包含返回的数据项，通过对这些数据项事先做好了相关的定义，无论是消费方还是生产者，只要遵循了契约测试的内容，就可以保证服务实时畅通的进行调用。契约测试通过验证Provider（生产者）是否按照期望的方式与Consumer（消费方）进行交互。

以下图为例，假设现在不同的服务提供方对同一个请求提供了不同的数据形式，这三个服务都有"id"。但第二种微服务比第一种微服务多了"age"字段，而第三个微服务和第一个微服务相比，虽然都包含"name"字段，但"name"字段里的数据是不一样的。此时如果是用接口测试来做的话，需要提供3个不同的请求来测试；但如果用契约测试来做的话，契约测试就相当于是这三个的全集，只需要定义一种契约即可。

在微服务测试时，想要实现环境无依赖，服务间无依赖？或者想要实现快速测试，支撑服务快速上线？这些都可以通过Mock测试来搞定，它就是在测试过程中，对于某些不容易构造或者不容易获取的对象，用一个虚拟的对象来创建以便测试的测试方法。

下图是蓝鲸DevOps平台提供的测试工具CTest产品功能架构图，从中可以看出无论是对于支撑不同的测试模式，还是测试报告应该具备的功能项，都已经有了相关的能力，是个较为成熟的产品。

5.编译构建

编译构建是指把软件的源代码编译成目标文件，并把配置文件和资源文件等打包的过程。

当前，业界最流行的编程语言还是Java，不同的编程语言都有不同的构建工具。对于流水线上的构建工具来讲，到底一款工具能支撑多少语言类型，也能考验一款编译构建工具的能力。

蓝鲸DevOps流水线效能实践工具，可以通过拖拽的形式构建流水线，不像一些开源工具，必须要会写脚本和手工配置。而蓝鲸DevOps流水线效能实践工具，已经把上述模块和组件内置了，降低了使用难度。

6.软件制品

软件研发过程中的“源码”和“软件制品包”（通常被通俗称为“二进制包”）都是很关键的资产。软件制品包通常是源码文件的集合或者编译后的产物，因此主要有二进制包和压缩包两种形式，软件制品包的管理和复用在发布管理有着关键的作用。

不同的编程语言，同样会对应不同的制品形式。现在之所以容器特别流行，就是因为它屏蔽了语言带来的限制，将包打成统一的格式，放到集群里边进行部署。

包文件通常不放在源码库中管理，而是使用专门的包文件仓库进行存储并配合包文件依赖管理工具（Maven、NPM、Ivy等）进行使用。包文件仓库可以大致分为本地仓库、私服仓库、中央仓库三种。

• 本地仓库是指开发者个人PC中包文件的存储
• 私服仓库通常是企业为了提升包文件使用性能搭建的局域网内共用的包文件仓库，通常使用开源的Nexus、Artifactory等工具搭建
• 中央仓库是指开源包文件的共享社区

私服仓库把源码仓库拉下来，通过持续构成的工具打包并存在私服仓库中。对依赖管理这块，比如项目和工程依赖一些开源的相关组件，那么私服就会把这些开源组件从互联网中央仓库拉下来，放到私服仓库上。开发人员在内网就可以根据需要，拉取代码或依赖包在本地做功能开发，做完后再提交到源码库，最终打成二进制介质放到私有仓库里。

▲ 图片来源网络，如有侵权请联系删除

 

什么是软件制品库？

软件制品库指能够统一管理各种类型的二进制制品，同时无缝对接现有的标准化构建和发布工具的软件平台。也就说制品库既能够存储中间产物，也能存储结果产物。“软件包”及其属性的管理是发布过程管理的基础，也是软件开发过程中的重要资产。

软件制品库在DevOps工具链中的开发集成、测试、生产等阶段都有作用，相关人员可在不同阶段把制品打完后放到制品库。一旦流程走到下一个环节，比如走到开发、测试，走到整个上线管理，制品也会做相应的晋级。

软件制品有多种格式，如Maven、Pypi、NPM等。

作为DevOps的重要枢纽，如果没有统一可信制品库，DevOps和CI/CD运转起来，就像流水线没了轴承，研发规模越大，问题和隐患就越多。虽然源码都是同一套，但是开发环境和测试环境的不同，会导致代码运行不起来。但如果能够保证在不同的环境下，用的都是同一个制品，那就能尽量少的屏蔽环境不同带来的影响。

比如经常听到“诶这个代码在我这里运行可以啊，怎么在你哪里运行不了？那肯定是你本地服务器的毛病。”因此，通过制品库的使用，能逐步避免这类现象的产生。

这个是我们在某客户那里的制品库落地案例。该客户是内外网隔离的，私服负责从外网的中央仓库下载依赖包，内网的依赖库和外网的私服库进行打通，以便于数据同步。所有内网的研发团队，都是从依赖库下载所需资源包，并做一些安全扫描等管理工作。由于该团队是分布式的开发团队，在全国各地都有相应的团队，每个城市都有自己的制品仓库作为本地的仓库节点，在开发中心有一个主节点，这样就把制品库做了一个主从的模式，以便制品的同步和晋级。

三、DevOps实现自动化部署

自动化部署可以减少人肉运维和手工运维的工作量，也能尽量避免人工操作所带来的的错误和风险。自动化部署是指将可交付产品，快速且安全地交付用户使用的一套系统和工具。系统会自动构建、测试并准备代码变更，以便将其发布到指定环境的过程，包括开发环境、预发布环境、生产环境等。

系统模板是自动化部署服务的关键特性。通过使用系统模板快速创建部署任务，然后将组合的部署步骤保存为自定义模板，这样在下一次部署任务来临时，就可以直接使用该模板。

我们把不同系统的发布策略做了一个整理汇总（见下图），如果实际应用场景具备这些能力项，就可以跟其他的组件相结合，对外提供不同的发布策略。

四、企业文化推广

有了前面的方法论，又该怎么开始准备和实施呢？

准备阶段1：选择合适的试点项目

从最有同理心和最乐于创新的团队开始，扩大DevOps的范围。在逐步扩大的过程中，发现创新者和早期采用者，赢得沉默的大多数，并识别意愿较低的“钉子户”。最后，尽早展示成果并积极宣传，将大目标分解成渐进式的小步骤。

Tips: 改进试点项目时，不但要努力降低复杂性，提高可靠性和稳定性，而且还应该更快、更安全、更容易变更，团队才可能更愿意尝试。

准备阶段2：组建全功能团队

软件开发团队的结构对软件产品的架构和成果有巨大的影响，利用康威定律组织团队，减少工作交接次数，提升交付速度和成功率。小团队独立运作，彼此充分解耦，避免过多的沟通与协调。牢记两个比萨原则，保持小规模。

准备阶段3：团队成熟度评估

在对团队进行成熟度评估时，可从价值、能力、角色三个方面进行考虑，参考业界端新型的研发能力框架对团队进行成熟度评估。

准备阶段4：价值流分析实例

• 召集所有关键成员，绘制价值流图。
• 记录主要的步骤和细节，让相关干系人员拥有同样的视图。
• 重点分析和优化，识别阻碍：需要等待数周甚至数月的工作；引发或处理重大返工的工作。
• 确定想要改进的度量指标，通过探索各种假设，然后分析结果，不断迭代和重复，将获得的经验用于下一次实验。

在实施阶段，确定实施的优先级，按优先级逐一推进。

• 团队敏捷：敏捷意识强化、知识点与工具使用培训、敏捷会议的观察及引导、测试前移、团队质量监控、SoS敏捷管理方法
• 业务敏捷：探求运用用户故事地图、实例化需求与用户故事、进行需求条目化、利用需求条目需求及任务分拆、形成统一的产品需求列表、探求估算与与迭代计划、探求需求沟通与反馈方式
• 工程敏捷：自动化单元测试、自动化代码扫描、自动化集成测试、自动化功能/流程测试、持续集成、持续交付、部署流水线、主干开发
• 管理工具：电子看板/物理看板、任务列表、项目状态 - 燃尽图、增值流图

DevOps是数字化转型成功的关键之一，虽然DevOps建设非一日之功，但是建成之后的价值不只能提升企业IT研发效能、交付质量和灵活应对业务需求的变化，对提升企业内部团队的协作和敏捷能力都有着显著变化。精彩未完待续，接下来我们还会邀请更多DevOps领域的专家为大家带来分享，请持续关注我们。如您有更多想探讨交流的话题，欢迎留言~