ITIL

DevOps的核心是研发效能改进，效能的提升离不开强大工具的支撑，因此在DevOps如火如荼的今天，承载研发效能改进的企业DevOps一体化平台工具建设变得非常炙手可热。

所以，工具链建设过程中，很多人都会有这些疑问：当前DevOps工具发展情况如何？为什么近期国内开始涌现大量的DevOps一体化工具平台，其中很多有实力的企业甚至自研DevOps一体化平台工具？自研DevOps一体化平台工具应该如何做？未来的DevOps发展方向会如何？

通过下面的内容使大家在DevOps工具建设过程中少走一些弯路。

一、当前DevOps工具发展情况

1.1 丰富的可用工具集

自从2010年DevOps这个专属名词推广开来以后，所有和软件研发过程管理相关的工具都可以划入到DevOps工具集中，这些工具从功能范围上可以分为两大类：

All-In-One类（DevOps一体化平台类）：即工具具备软件研发主要过程的管理能力，例如上图中微软的Azure DevOps，Atlassian的全家桶（包括我们熟知的Confluence，Jira，Bitbucket，Bamboo等）。

领域专注类：这类工具大都只专注于一种或者多种能力，例如只专注于条目化跟踪管理的Jira，禅道，Clickup等，这些工具大多核心能力是进行条目化跟踪管理的，可以覆盖需求、变更以及缺陷等多种企业常见软件研发管理流程。

1.2 井喷式出现的国内DevOps工具

当前国内出现了大量的DevOps一体化平台工具，例如阿里的云效、华为的DevCloud、京东的行云，Gitee，博云等诸多商用DevOps一体化平台工具。当然也有很多企业开始自研平台工具。导致这种状况的主要原因有三个：

• 随着开源社区的发展，使得企业基于开源工具定制化更加适合自身要求的平台工具越发简单。
• 国内的软件行业经过多年发展，逐渐形成了一套适合自身需要的管理方法，也诞生了诸多优秀工具。随着企业对工具的整合，逐渐具备了DevOps一体化平台的基础。
• 部分企业由于国际环境原因，开始逐步放弃国际上成熟的优秀DevOps一体化平台工具，转而在国内寻求优秀替代品，或者干脆自行研发。
  
  

1.3 国内DevOps工具建设问题

虽然目前市场上有很多国内的DevOps产品，但是或多或少会有一些开源工具的影子，有些干脆就是基于开源工具套了一个壳子。这种方式可以让产品快速投入使用，但是同时也会有很多的问题。

• 技术封装不到位
• 流程管理模式僵化
• 扩展性差、定制化强烈依赖二次开发
• 管理维度能力较强，工程维度专业度不足
• 可度量设计缺失、数据分散
  
  

二、DevOps工具优化方案

2.1企业DevOps一体化平台能力

一款好的DevOps平台产品从研发流程跟踪与管理，到端到端的自动化高质量制品生成及交付，应该具备强大的业务功能：

研发过程覆盖

应该完整覆盖软件研发的主要过程：流程跟踪（需求、变更、缺陷以及测试等），源代码管理，自动化流水线，测试管理，制品管理等。

开箱即用

为最大限度的满足主要客户需求，提供开箱即用的配置及工具，例如：提供敏捷、看板等管理工具，提供主流技术栈的流水线开箱即用模板，并且提供调用主流自动化测试工具以及环境部署的流水线任务。

团队协作

在工程管理维度上，应该具备跨系统，跨团队的协同管理能力。

端到端的DevOps工具链

一定要具备协助企业搭建端到端的DevOps广义流水线的能力。也就是说基于DevOps平台工具可以将涉及软件研发的所有流程工具、研发工具、测试工具及运维工具等统一整合起来的能力。

DevOps度量体系

如果希望建立企业级的DevOps持续改进机制，能有一种持续可行的研发效能提升体制，那么研发度量一定是必不可少的最重要依据。在当下工具功能已经足够完善的情况下，产品的最大卖点应该是帮发现问题，分析问题，以及提供解决问题的数据依据，最后成为企业持续改进的内建度量标准。

一切皆代码

DevOps一体化平台工具除需求管理外，其他主要功能模块应该都可以通过脚本进行编排，即Everything As Code（一切皆代码）。

2.2 DevOps一体化平台结构

• 具有普适性的基础管理能力
• 具有灵活的流程管理配置能力
• 具有完善的产品扩展能力
  
  

•    对外提供标准Web API
•    基于DevOps一体化平台产品的扩展框架
•    完善的消息推送机制
  
  

• 不可或缺的产品定制化能力
  
  

三、DevOps工具链的终极形态构想

未来的编码趋势一定是IDE轻量化，这点大家可以查一查现在Web IDE的热度，VS Code在短时间内收获大量用户就是一个最好的证明。那么基于IDE的网页化，DevOps一定将走向轻量化，不应该再像现在一样，需要维护一个功能复杂的工具界面，这些功能应该被直接集成在IDE中。DevOps平台工具在功能设计上应该只有3个核心模块：流程管理，后台服务，度量。

• 流程管理：主要提供给利益干系人、管理者进行信息查看和流程操作使用，此功能需要有对外展示页面。但是开发团队只需要使用轻量化的IDE完成所有操作即可，所有信息与操作均可以在IDE上直接、精确的显示与操作。
• 后台服务：提供包括代码管理、流水线管理和制品管理等其他核心服务。
• 度量：可以根据任意维度显示所有与开发活动相关的数据，包括流程管理数据、工程管理数据、行为数据（例如开发人员的代码开发习惯，开发时长，代码质量分析等等）。并且可以快速的形成报表进行展示。
  
  

从技术上，整个环境应该都运行在基于容器化编排平台运行的容器中，并且相较于传统DevOps平台工具上的差异：

• 环境：DevOps平台工具、开发IDE、DevOps自动化流水线运行环境、应用运行环境
• DevOps组件：丰富的DevOps功能接口、通用化JS集成框架、实时的研发数据动态收集功能
• DIS（DevOps Integration Service)：易于配置的集成服务、兼容主流DevOps工具集、开源化运营，便于使用者的二次定制化（转自薄涛）
  
  

ITIL

DevOps的核心是研发效能改进，效能的提升离不开强大工具的支撑，因此在DevOps如火如荼的今天，承载研发效能改进的企业DevOps一体化平台工具建设变得非常炙手可热。

所以，工具链建设过程中，很多人都会有这些疑问：当前DevOps工具发展情况如何？为什么近期国内开始涌现大量的DevOps一体化工具平台，其中很多有实力的企业甚至自研DevOps一体化平台工具？自研DevOps一体化平台工具应该如何做？未来的DevOps发展方向会如何？

通过下面的内容使大家在DevOps工具建设过程中少走一些弯路。

一、当前DevOps工具发展情况

1.1 丰富的可用工具集

自从2010年DevOps这个专属名词推广开来以后，所有和软件研发过程管理相关的工具都可以划入到DevOps工具集中，这些工具从功能范围上可以分为两大类：

All-In-One类（DevOps一体化平台类）：即工具具备软件研发主要过程的管理能力，例如上图中微软的Azure DevOps，Atlassian的全家桶（包括我们熟知的Confluence，Jira，Bitbucket，Bamboo等）。

领域专注类：这类工具大都只专注于一种或者多种能力，例如只专注于条目化跟踪管理的Jira，禅道，Clickup等，这些工具大多核心能力是进行条目化跟踪管理的，可以覆盖需求、变更以及缺陷等多种企业常见软件研发管理流程。

1.2 井喷式出现的国内DevOps工具

当前国内出现了大量的DevOps一体化平台工具，例如阿里的云效、华为的DevCloud、京东的行云，Gitee，博云等诸多商用DevOps一体化平台工具。当然也有很多企业开始自研平台工具。导致这种状况的主要原因有三个：

• 随着开源社区的发展，使得企业基于开源工具定制化更加适合自身要求的平台工具越发简单。
• 国内的软件行业经过多年发展，逐渐形成了一套适合自身需要的管理方法，也诞生了诸多优秀工具。随着企业对工具的整合，逐渐具备了DevOps一体化平台的基础。
• 部分企业由于国际环境原因，开始逐步放弃国际上成熟的优秀DevOps一体化平台工具，转而在国内寻求优秀替代品，或者干脆自行研发。
  
  

1.3 国内DevOps工具建设问题

虽然目前市场上有很多国内的DevOps产品，但是或多或少会有一些开源工具的影子，有些干脆就是基于开源工具套了一个壳子。这种方式可以让产品快速投入使用，但是同时也会有很多的问题。

• 技术封装不到位
• 流程管理模式僵化
• 扩展性差、定制化强烈依赖二次开发
• 管理维度能力较强，工程维度专业度不足
• 可度量设计缺失、数据分散
  
  

二、DevOps工具优化方案

2.1企业DevOps一体化平台能力

一款好的DevOps平台产品从研发流程跟踪与管理，到端到端的自动化高质量制品生成及交付，应该具备强大的业务功能：

研发过程覆盖

应该完整覆盖软件研发的主要过程：流程跟踪（需求、变更、缺陷以及测试等），源代码管理，自动化流水线，测试管理，制品管理等。

开箱即用

为最大限度的满足主要客户需求，提供开箱即用的配置及工具，例如：提供敏捷、看板等管理工具，提供主流技术栈的流水线开箱即用模板，并且提供调用主流自动化测试工具以及环境部署的流水线任务。

团队协作

在工程管理维度上，应该具备跨系统，跨团队的协同管理能力。

端到端的DevOps工具链

一定要具备协助企业搭建端到端的DevOps广义流水线的能力。也就是说基于DevOps平台工具可以将涉及软件研发的所有流程工具、研发工具、测试工具及运维工具等统一整合起来的能力。

DevOps度量体系

如果希望建立企业级的DevOps持续改进机制，能有一种持续可行的研发效能提升体制，那么研发度量一定是必不可少的最重要依据。在当下工具功能已经足够完善的情况下，产品的最大卖点应该是帮发现问题，分析问题，以及提供解决问题的数据依据，最后成为企业持续改进的内建度量标准。

一切皆代码

DevOps一体化平台工具除需求管理外，其他主要功能模块应该都可以通过脚本进行编排，即Everything As Code（一切皆代码）。

2.2 DevOps一体化平台结构

• 具有普适性的基础管理能力
• 具有灵活的流程管理配置能力
• 具有完善的产品扩展能力
  
  

•    对外提供标准Web API
•    基于DevOps一体化平台产品的扩展框架
•    完善的消息推送机制
  
  

• 不可或缺的产品定制化能力
  
  

三、DevOps工具链的终极形态构想

未来的编码趋势一定是IDE轻量化，这点大家可以查一查现在Web IDE的热度，VS Code在短时间内收获大量用户就是一个最好的证明。那么基于IDE的网页化，DevOps一定将走向轻量化，不应该再像现在一样，需要维护一个功能复杂的工具界面，这些功能应该被直接集成在IDE中。DevOps平台工具在功能设计上应该只有3个核心模块：流程管理，后台服务，度量。

• 流程管理：主要提供给利益干系人、管理者进行信息查看和流程操作使用，此功能需要有对外展示页面。但是开发团队只需要使用轻量化的IDE完成所有操作即可，所有信息与操作均可以在IDE上直接、精确的显示与操作。
• 后台服务：提供包括代码管理、流水线管理和制品管理等其他核心服务。
• 度量：可以根据任意维度显示所有与开发活动相关的数据，包括流程管理数据、工程管理数据、行为数据（例如开发人员的代码开发习惯，开发时长，代码质量分析等等）。并且可以快速的形成报表进行展示。
  
  

从技术上，整个环境应该都运行在基于容器化编排平台运行的容器中，并且相较于传统DevOps平台工具上的差异：

• 环境：DevOps平台工具、开发IDE、DevOps自动化流水线运行环境、应用运行环境
• DevOps组件：丰富的DevOps功能接口、通用化JS集成框架、实时的研发数据动态收集功能
• DIS（DevOps Integration Service)：易于配置的集成服务、兼容主流DevOps工具集、开源化运营，便于使用者的二次定制化（转自薄涛）