背景：

DevOps已经成为软件开发领域一个炙手可热的名词。敏捷开发、持续交付、CI/CD，K8s…这些主流的开发理念、工具无一例外都与DevOps有着很强的联系。这种环境影响下，传统的运维团队均开始向DevOps进行转型。一时之间运维开发、SRE、工程效能工程师需求量大增，无论公司大小，都会开始着手DevOps的从0到1的建设。我们开始搭建工具链、部署流水线、集成自动化测试工具、开发自动化发布系统……一切的一切都是为了完善我们自动化体系，从而提高开发效率，优化产品质量。
那么问题来了，你团队所建设的DevOps体系，已经是完善的DevOps了么？

正文：

我们如何去评估目前DevOps中持续交付的建设情况呢，这里笔者总结了一些我们在DevOps初期应该进行的一些工作，这些工作大多数属于工具链的集成，我们可以对照下述十四条关卡，来验证一下我们的DevOps建设中持续交付这一环节是否走在了一条正确的道路上吧。

1， 版本控制

版本控制是指通过记录软件开发过程中的源代码、配置信息、环境、数据等，快速的恢复及访问任意一个版本。版本控制最主要的功能就是追踪文件的变更。
常用版本管理工具：git

2， 最优分支策略

分支的种类很多，大多数团队会使用到主干分支、开发分支、临时分支、功能分支、预发布分支、bug修复分支等等。那么如何选择一个最优分支策略，是我们开发团队必须去规范的一件事。分支策略与版本发布频率之间有一定的相关性，我们要根据自己团队开发模式以及项目迭代周期来选择最优的分支策略。

3， 代码静态扫描

代码静态扫描需要从下面几个维度进行检查：复杂度分布、重复代码、单元测试统计、代码规则检查、注释率、潜在BUG、结构与设计。通过在构建pipeline中加设代码静态扫描的质量关卡，确保我们的代码可以达到一个可发布的级别。
常用的代码静态扫描工具：如SonarQube。

4， 80%以上单元测试覆盖率

提高单元测试的意义最重要的一点是保证代码所对应的功能正常、而单元测试覆盖率的检查是以一种约束方式来规范开发人员使用单元测试，通过设置单元测试覆盖率的关卡来保障开发代码的正确性，并让单元测试逐渐地变成开发习惯。

5， 漏洞扫描

每个项目中，高达99.9%的代码来自于外部依赖，为了避免重复造轮子，我们引用了大量的外部开源框架及组件，这些外部依赖是否有安全，是否存在高危漏洞，开发人员一般是无法关注到的，所以我们需要一款产品可以集成到我们开发的IDE、设置成为构建流程pipeline中的质量关卡、无缝的对接到我们的制品库中，来扫描我们所有的外部依赖。
常用漏洞扫描工具：JFrog Xray

6， 制品管理

制品是构建过程的产出物。包括软件包、测试报告、应用配置文件等。制品管理是对软件研发过程中生成的产物的管理，一般作为最终交付物完成发布和交付。你所管理的制品可以统称为二进制文件，制品仓库则可以提供所有二进制文件的管理能力，提供全语言的依赖解析能力以及收集整个软件生命周期的信息与制品关联。
常用制品管理仓库：Artifactory

7， 开源协议扫描

开源协议有上百种，宽松程度不一。是否允许商用、是否可以修改、修改后是否需要继续开源等都是每种协议特有的特性。我们作为用户，作为开发者，为了提高开发效率，避免重复造轮子，难免会引用大量的外部组件及框架，那我们在DevOps建设过程中则必须注意对开源协议的管理及扫描。
常用的开源协议：
? Apache 2：直接使用须保留原始许可声明，若对其进行修改，需向用户说明。
? MIT：必须保留原始许可证声明
? BSD：必须保留原始许可证声明，部分版本不得使用原作者姓名用于软件销售
? GPL：若包涵GPL代码，整个项目则必须使用GPL许可证。
常用的协议扫描工具：JFrog Xray。

8， 不可变基础设施

不可变基础设施是指任何基础设施实例在部署后永远不会被修改。如果需要以任何方式更新，修复或修改某些内容，则会使用一批新的实例去替换，并在经过验证后，将新的基础设施实例上线，替换掉旧的实例。这种在当年在物理机或虚拟机上无法快速实现的这种不可变基础设施的理念，随着docker的普及正在飞快的发展，我们可以通过容器的方式快速的实现。这种模式可以为我们减少配置管理的负担，并使得 DevOps 更加容易实践
最佳实践方式：Docker

9， 集成测试

集成测试是在单元测试的基础上，把软件单元按照软件概要设计规格说明的规格要求，组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求。

10， 性能测试

性能测试方法是通过模拟生产运行的业务压力量和使用场景组合，来测试系统的性能是否满足软件的性能要求。通俗地说，这种方法就是要在特定的运行条件下验证软件系统的处理能力。

11， 变更管理

在google的SRE体系中，变更管理是DevOps体系中最为重要的一个部分。根据以往的经验，90%的线上故障是由于线上变更导致的，该变更原因包括软件、硬件、环境等所有因素。建设变更管理体系目的就是为了快速定位线上问题，止损由于变更造成的线上故障，及时通知相关人员做好故障预防工作。所以，变更管理体系也是需要我们重点去建设以及完善的。
落地方式包括但不限于下述几点：
? 运维人员、对应的开发及测试人员、产品经理等微信通知
? 大屏滚动播放最近的变更记录
? 变更记录同步到监控系统

12， 功能开关

功能开关概念很容易理解，通过功能开关我们可以在运行过程中对某一功能进行启动和关闭，在敏捷开发模式下，为了快速迭代，在某些团队没有完全准备好的情况下，我们可以通过功能开关的方式将新功能上线并通过配置屏蔽该功能，直至所有团队准备就绪，整个功能涉及到的服务全部上线后，可以打开此功能开关，提供用户使用。
通过功能开关的方案，我们可以快速迭代，不必进行复杂的集成测试及大版本交付，实现真正的敏捷开发、小步快跑。

13， 较高的接口测试覆盖率

提高接口测试覆盖率就意味着我们可以提高自动化测试的覆盖率，在每次构建流水线中可以自动部署我们的项目，通过接口测试来实现基础的自动化测试。另外接口测试可以提供给运维平台一个监控服务是否稳定的依据，我们可以通过监控平台实时触发接口测试，来判断线上的服务是否依然稳定运行。通过这种接口测试，我们可以最快的速度定位到某些线上某些功能的故障。

14， 零停机发布

无论使用蓝绿部署、还是金丝雀发布，我们的目标只有一个，就是零停机发布。零停机发布是指在对用户不停止服务的前提下进行版本的迭代，修复bug、引用新功能等操作。是否拥有一个健全的零停机发布体系也将是我们DevOps建设中十分重要的一个步骤。

总结：

DevOps并不是我们建设起来工具链就可以实践的一个理念，文中所介绍的十四个关卡也仅仅是DevOps体系中小小的一部分。开发团队组织架构的合理性、安全风险管理能力、技术运营、需求管理、架构设计、工程师文化等都是我们DevOps建设过程中需要探讨的课题。

原文地址：https://blog.51cto.com/jfrogchina/2464105