企业DevOps一体化平台建设思路 - 终极形态是什么？

公司及个人简介

我所在的 英捷创软科技（北京）有限公司 (leansoftX.com)是一家专注于软件工程，敏捷开发和DevOps领域产品开发和服务的解决方案提供商。公司由15年 软件研发经验,资深ALM/DevOps专家创建并任公司首席架构师，至今已经为超过100家不同类型和规模的客户提供过DevOps解决方案的咨询和落地服务。公司在软件研发效能领域具有多项获得国家级计算机著作权的自主研发产品。公司及成员具有多项业界认证，包括：EXIN DevOps Master, 认证 ScrumMaster，华为云最有价值专家，微软最有价值专家，微软金牌合作伙伴，GitHub在中国唯一的授权服务合作伙伴等。

薄 涛

英捷创软 咨询服务总监

本人从事为企业提供研发效能改进解决方案相关工作十几年，为国内上百家企业提供过DevOps咨询及解决方案落地解决方案，涉及行业包括：金融、通信、制造、互联网、快销等多种行业。通过对企业的研发现状的深入了解，协助企业建设、优化DevOps平台，给出研发管理流程落地的最佳实践方案，协助企业进行DevOps研发效能改进内部试点，总结试点经验，最终逐步进行企业级推广，同时也为企业提供DevOps平台工具优化解决方案，帮助其建立功能完善，并易于扩展及维护的端到端DevOps工具链。

自从2020年开始，我们公司开始承接了更多的DevOps工具链改进的项目，随着工具市场的激烈竞争，更多企业希望从设计、功能、易用性等方面优化自己的产品，我或主导或参与了这些项目，因此在这想聊一聊我对DevOps工具链的理解，以及对国内DevOps工具的一些自身看法及建议。

介绍

DevOps的核心是研发效能改进，效能的提升离不开强大工具的支撑，因此在DevOps如火如荼的今天，承载研发效能改进的企业DevOps一体化平台工具建设也变得炙手可热。在工具链建设过程中，很多人都会有这些疑问：当前DevOps工具发展情况如何？为什么近期国内开始涌现大量的DevOps一体化工具平台，其中很多有实力的企业甚至自研DevOps一体化平台工具？自研DevOps一体化平台工具应该如何做？未来的DevOps发展方向会如何？希望能通过下面的内容使大家在DevOps工具建设过程中少走一些弯路。

当前DevOps工具发展情况

软件研发管理从最早的粗犷的混乱管理模式，到现在通过完整工具支撑的精细化管理，这个过程漫长而艰辛，在这期间出现过很多很多的方法、框架、工具甚至是思想。有些随着技术的发展在逐步进步，但也有些渐渐的淡出软件研发这个圈子。

在2010年以前，我们使用的工具大部分都是由国外的软件公司或者开源社区提供的，从2010~2015年国内已经逐步诞生了一些软件研发管理相关工具，2015年以后随着国内软件研发管理的逐步完善，DevOps相关工具开始大量涌现。这些工具有些是专注于软件研发的某个领域，有些则旨在打造一个完整的DevOps管理平台。

本人从2012年开始进入企业研发效能改进解决方案咨询行业以来，即接触过国际上主流的工具，也接触过国内的一些新兴工具。给我的·感受就是国际主流工具功能强大，可扩展能力强，但是确实在设计理念上与国人的软件研发管理思维方式有差异，不能说无法使用，只是让我们不习惯。国内的工具普遍的问题就是缺少时间的积累和打磨，某些产品在设计上有着强烈的自身企业研发管理基因，但是从设计角度来讲，较为符合国人的使用习惯。

丰富的可用工具集

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

All-In-One类（DevOps平台类）：即工具具备软件研发主要过程的管理能力，例如上图中微软的Azure DevOps，Atlassian的全家桶（包括我们熟知的Confluence，Jira，Bitbucket，Bamboo等）。这些工具的特点就是基本可以通过一款工具帮助企业实现从需求跟踪到环境发布的所有管理要求，不需要企业为了不同管理目的采购不同软件，极大的降低了管理、维护与学习成本。但这并不意味着企业只需要这一款工具就能解决所有软件研发过程中的问题，例如：大部分All-In-One产品是没有质量相关管理功能的，例如：静态代码扫描，接口测试工具，安全扫描工具，压力/性能测试工具等。

领域专注类：这类工具大都只专注于一种或者多种能力，例如只专注于条目化跟踪管理的Jira，禅道，Clickup等，这些工具大多核心能力是进行条目化跟踪管理的，可以覆盖需求、变更以及缺陷等多种企业常见软件研发管理流程。条目化管理工具的特性就是以表单式条目化基础结构，加上不同类型条目的流程设置使其具备不同软件研发流程的跟踪能力。这些工具的功能较为单一，无法通过一款工具覆盖完整的软件研发管理。但是好处就是使用者可以根据自身需要，选择最优化的工具集来进行软件研发管理，这样可以最大限度的满足不同研发过程对于某些特殊功能的要求，也能通过尽量使用开源工具降低成本，但由于工具多而杂也带来了维护成本大，管理及使用复杂的问题。同时如果使用者希望能深度改进软件研发管理时，如何获取研发大数据也会由于工具集的复杂度带来诸多问题。

领域专注类工具庞杂，专业性强我们不在这儿逐一讨论了，后面我主要针对DevOps平台类产品进行分析。

井喷式出现的国产DevOps工具

国内的软件行业经过多年发展，逐渐形成了一套适合自身需要的管理方法与工具，同时随着开源社区的发展，也使得企业基于开源工具定制化更加适合自身要求的平台工具越发简单。因此很多企业开始基于开源工具内建自己的企业级DevOps一体化平台工具，并通过多年内部使用，产品从功能到质量都在逐步完善，当企业认为工具已经成熟并可以商业化时，就将其推向了市场；也有些企业对标国际上成熟的DevOps平台工具，同时融入国内软件研发管理习惯，开始研发商用DevOps一体化平台产品。

我所接触的很多客户，都开始自建DevOps平台，大部分采用的也都是对开源产品的封装，然后再融入自身的研发管理流程，使其更加符合企业内部的研发管理需要。

同时我们也接触了很多还不错的国内DevOps平台产品，例如：Gitee，博云，阿里云云效，华为云DevCloud等等。现在我接触过的很多企业都开始自研DevOps平台工具，目的是国产替代，以及为了提供更加适配企业流程的管理要求。

国内DevOps工具建设问题

其实DevOps平台工具的开发需要很大的投入，以微软的Azure DevOps举例，从微软2005年正式对外发布产品化Team Foundation Server（Azure DevOps前身）开始，经历了17年的不断开发与优化，才有了目前国际市场上被广泛认可的Azure DevOps。在此期间Azure DevOps为了适应不断变化的软件研发管理实际要求，也经历了数次大的技术调整与重构。由此可见想一蹴而就的研发一款优秀的DevOps产品基本是不可能的。

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

• 技术封装不到位：这类产品的最大特点就是只是对开源产品进行类简单的封装，但由于封装的不到位，导致了在运行自开发产品的同时，需要维护底层的开源产品。我也见到过一些产品，在基于开源产品进行优化时反而降低了开源产品具备的优秀能力，提高了使用难度，这就有点儿得不偿失了。

• 流程管理模式僵化：DevOps平台需要具备的研发流程管理，配置管理，自动化流水线，制品管理，环境管理等重要模块功能中，除了研发流程管理，其他的主要功能每个产品的功能差异性不是很大。最能体现产品特色的就是研发流程管理。并且我在国内接触到的所有客户几乎都将流程管理视为DevOps平台工具的最重要功能，也是我们在提供解决方案时，需要帮助客户着重梳理的部分。但是很多产品在设计这部分时，都只支持敏捷、看板或者带有自管理方式的流程。研发流程上每个企业都或多或少的存在差异，尤其是在一些中大型的软件研发部门或企业中，固化的流程管理方式很难适配所有团队。

• 扩展性差、定制化强烈：国内的很多产品是都支持企业级用户的，但往往在适配企业用户时需要对现有产品进行定制化才能将企业管理流程进行落地。定制化方式往往仅限于基于现有产品的定制化开发。其实基于产品的定制化开发应该是最后才考虑的，这样做会导致后期维护成本高，同时会给版本升级，产品功能迭代带来诸多质量问题。

• 管理维度能力较强，工程维度专业度不足：我接触的DevOps平台产品可以覆盖软件研发的主要过程，但是很多产品在设计的时候并没有考虑到从工程维度的版本交付维度进行管理，这导致了在当前软件研发过程中很多DevOps平台产品都是以项目 / 系统 / 团队范围内的研发管理，但是由于很多企业的不同产品间是存在耦合的，很多时候需要不同系统协同开发与发布，而很多DevOps平台产品对跨系统支持的并不好。正确的做法应该是从管理维度上平台工具应该覆盖软件研发的所有过程，从工程维度上来讲，要具备软件发布版本上的协同研发管理。

• 可度量设计缺失、数据分散：有些DevOps平台的研发数据分别存储在不同功能模块中，各个模块数据没有联系，这种情况尤其体现在基于开源产品的封装式产品上；有些则无法简单的定制化度量报表。

英捷创软的DevOps工具链优化案例

1.华为云DevCloud -- HE2E框架

华为DevCloud软开云是华为云系列产品中专门提供DevOps工具链的一体化解决方案，Leansoft专家团队作为华为云MVP与华为DevCloud团队共同制定了一套HE2E DevOps实施推广框架，并在过程中不断的帮助DevCloud产品团队打磨优化产品，提升平台自身的用户体验以及产品质量。

我们通过设计一个实践标准敏捷管理的凤凰商城样例项目，来验证DevCloud产品各个领域模块的能力，根据验证情况提出相应的改进建议，再由DevCloud产品以及研发团队改进产品。并通过将此样例项目固化到DevCloud内置项目模版的方式，让用户可以通过创建此样例项目，配合对应的HE2E DevOps实践指导手册，让用户可以结合场景、故事、事件完整一个端到端的DevOps旅程。这样即帮助用户了解了DevOps相关的文化以及实践，又让用户对于如何使用DevCloud平台进行研发管理有了初步的了解。

2.某某云

某某云是国内知名大型企业旗下的云服务品牌，是全球领先的云计算服务商，为数百万的企业和开发者提供安全可信、云网一体、专属定制、多云协同的高质量云服务。

XX作为某某云自研的企业级DevOps一体化平台产品，具有强大的流程管理、源代码管理、自动化流水线和测试管理功能。XX目前主要作为内部研发管理平台使用，在产品逐步完善后，会作为某某云产品的一个重要部分推向市场。

协助改进某某云的Devops平台产品，此产品目前还处于研发阶段，主要是内部使用。由于内部自研产品特性导致各系统间耦合性较高，部门间的协同开发情况较多，因此迫切需要在平台产品中提供一种可以帮助研发团队实现协同开发的功能。

项目为基于XX平台定制一整套从需求到交付生产制品的全研发流程落地管理规范，首先我们在不进行定制化开发的情况下，制定了一整套基于现有功能的版本管理方法，当然这里需要进行较多的手动信息整理与维护，然后在试点团队中验证这种方法是否可以帮助团队实时掌握自身版本以及协同开发系统的指定版本信息，然后再将此功能固化到XX平台产品中，在此过程中也发现了很多工具无法支撑整个过程的情况，这也是我们对于工具提出的改进建议依据。

最终形成了以版本为信息为核心的统一协同管理，通过版本可以查看和操作整个版本研发过程相关的需求，版本分支，流水线运行，环境部署结果，测试结果等信息。同时通过各系统间的版本关联，可以查看其他相关系统的版本研发进度与相关详细信息。

通过这种方式，即验证了DevOps平台工具的版本管理可行性，也同时优化了产品的功能。

DevOps工具优化方案

经过多年的DevOps解决方案咨询与实施工作，加上这些年逐步深入的DevOps工具链优化改进项目，如下列举了我对DevOps工具设计的一些看法。

企业DevOps一体化平台能力

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

研发过程覆盖

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

开箱即用

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

团队协作

在工程管理维度上，应该具备跨系统，跨团队的协同管理能力。每个研发团队基本都需要经过需求、开发、测试、发布等主要过程，这也是很多DevOps平台产品在设计时只考虑从管理维度出发覆盖了这些主要的研发过程，但是并没有从工程管理维度出发去考虑当一个系统存在与其他系统存在耦合，需要协同发布时的场景，不要说这是产品设计的问题，为什么不重构为微服务，当你接触的客户多了你会发现，出现这种为题客户最希望的是通过工具来解决，而不是重构自己的产品。因此DevOps平台产品一定要考虑如何进行协同开发管理。这部分也是我在为客户做工具改进时的一个重点部分，这里你应该先考虑清楚一个问题，到底从哪入手进行协同开发管理才是最佳的？是从流程上还是组织上？其实最好的协同方式是以工程维度的软件版本管理上入手才是最佳方案。例如：一家大型金融企业（金融企业的系统耦合度普遍很高）当系统A进行新功能开发时，需要系统B、C和D等三个系统进行协同开发，这时我们可以分别在四个系统中定义自己的版本，并将四个版本关联起来（也可以考虑定义一个版本），每个系统的版本中应该包含：版本实现的需求有哪些，修改了哪些仓库的哪些代码，当前版本的流水线运行情况（包括编译、自动化测试以及部署等），各个环境的质量验证情况，并且这些版本信息对于所有相关团队都是开放的，那么这样所有此需求的相关人员都可以实时的了解当前系统以及依赖系统的研发集体信息，可以极大的减少由于信息不明导致的系统发布失败或延期的情况。

端到端的DevOps工具链

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

DevOps度量体系

完善的度量体系：现在大多数客户对于产品的选择主要是集中在功能性上，但是如果我们希望建立企业级的DevOps持续改进机制，希望企业能有一种持续可行的研发效能提升体制，那么研发度量一定是必不可少的最重要依据，但是现在所有产品在这部分做的都不好，大家还是主要关注的产品功能，在当下工具功能已经足够完善的情况下，产品的最大卖点应该是帮你发现问题，帮你分析问题，以及提供解决问题的数据依据，最后成为企业持续改进的内建度量标准。举例来说：大家都知道DevOps的本质就是研发效能改进，那DevOps咨询服务的起点应该就是企业研发效能的现状评估，如果有一款工具能从管理维度上提供团队的研发效率，交付效率，产品质量，效能瓶颈，以及团队间的协同效率或者说组织效率相关数据，再结合工程维度的端到端的版本交付相关数据，那么一个团队或者一个组织的基础能力就能很容易评估，同时也更佳方便企业分析自身问题，为解决问题提供最优改进方案数据依据。

一切皆代码

基础架构即代码是一个重要的DevOps最佳实践。但是最为一款好的DevOps平台工具，自身应该具备功能强大，使用灵活简单的基本特性。如何实现此特性？首先应该清楚，作为一个软件系统的研发管理过程主要包含哪些内容：需求，应用源代码、数据库、测试、制品生成、运行环境及其他依赖。除了需求以外，其他应该都可以用脚本来编排，例如：通过脚本实现数据库持续交付，通过脚本实现自动化测试，通过脚本实现流水线编排和环境编排。因此DevOps一体化平台工具除需求管理外，其他主要功能模块应该都可以通过脚本进行编排，即Everything As Code（一切皆代码）：开发人员在自己的IDE中就可以掌控软件工程维度管理内容，自动化测试脚本帮助开发团队内建质量在代码中，数据库脚本帮助研发团队实现软件的完整交付，流水线脚本帮助开发人员简单快速的配置及维护流水线，环境编排脚本用来定义软件运行环境及所有运行依赖，目前基础架构即代码实践的最优方案是将容器化应用部署到基于容器化的微服务编排平台来实现，其次可以考虑使用云产品来支持，私有云可以通过CHEF,Puppet,Ansible这种环境编排工具来实现，但是这种方案的复杂度高，维护成本大，并不推荐。如果想软管团队的DevOps工程管理能力变得优秀，那么实现一切皆代码是最终的归宿。

DevOps一体化平台结构

如果DevOps平台工具光具备好的业务能力是不足够的，还应该具有优秀的产品结构。如何让产品易于部署与维护，如何适配不同企业、不同团队及不同流程，这些问题都需要通过产品设计来解决，如上图的产品结构就是一款优秀DevOps平台工具需要具备的：

具有普适性的基础管理能力

核心功能具备软件研发管理的基础能力，也就是说应该面向最广泛的用户，提供最通用化的研发管理基础能力。比如说Gitlab内置的Issue管理功能，可能对于大型研发组织来讲Issue无法落地所有研发流程，但是如果只将范围限定在只负责一个微服务或模块研发的研发团队，Issue功能足以支撑其研发管理需要的，并且其对于不同流程的适配能力其实也很强，无论是敏捷/瀑布还是其他流程都可以匹配。同时产品的各个功能模块应该具备良好的衔接能力，例如：从需求到任务，从任务到代码，从代码到制品，从制品到环境，从制品到缺陷，这个软件研发的端到端的环节应该被完整的串联起来，具备可以通过过程中的任意一点追溯整个过程的能力。

具有灵活的流程管理配置能力

为了适配不同行业，不同企业，可以通过产品的配置化功能进行研发管理流程落地。之前也提到过，不管是配置管理还是自动化流水线，这些功能在各个工具上的差异并不是很大。配置管理上现在都是采用的主流工具Git，再结合拉取请求（合并请求）进行代码集成管理。流水线的基础功能大同小异，核心功能都是制品生成、发布以及自动化质量控制。因此最能体现产品特色的就是流程管理，能否更好的落地不同企业的研发管理过程，主要取决于工具的流程管理可配置性。还是拿微软的Azure DevOps来举例，如果是一个小型企业使用，不需要配置，原生使用就足够了。对于一个中型的软件研发企业，他们有着自己的流程，自己内部已经形成了通用的业务术语，那就需要进行简单的过程管理配置了。但是对于一个大型的金融企业来讲，原生功能外加原生配置也无法满足要求的，那就不得不进行一些定制化开发了。特别是对于传统制造业企业（比如汽车制造）来讲，如果想使用Azure DevOps进行工业产品研发过程的完整覆盖，不管如何配置及定制化开发都会觉得很别扭，这就是由于传统制造行业中的软件研发管理是有别于互联网式的软件研发管理的。

具有完善的产品扩展能力

优秀的产品化DevOps平台工具必须具备完善的扩展能力，这可以使产品获得更大的用户群体，降低产品售后的实施难度，可以将产品的研发团队以及支持企业客户的技术支持团队解耦，降低管理成本。同时用户在使用上也具备更大的自由度，可以在框架之下灵活扩展，使原本无法满足需求的DevOps平台工具实现研发流程的完整支撑。打造完整企业级DevOps工具链也要求核心的DevOps平台工具具备良好的扩展能力。

对外提供标准Web API

从后台管理相关的系统用户、安全设置、系统设置等，到流程、源代码、流水线、测试以及制品等前台管理的所有功能都应该有相关接口提供，也就是用户能在产品上使用的大部分功能都应该提供相关的接口，并且这些接口能做到产品升级后对于旧接口版本的向下兼容。

通过Web API调用，用户可以自行进行需要的扩展功能开发，例如：如果需要在项目管理工具中将通过审批的项目、工单或需求同步到DevOps平台工具中，则可以在项目管理系统中通过调用接口实现信息推送。

基于DevOps一体化平台产品的扩展框架

DevOps一体化平台工具需要具备定制化扩展框架，基于框架可以对产品功能界面、菜单和某些功能进行调整，这样就能满足绝大多数对于产品定制化的要求。

例如下图就是Azure DevOps的扩展定制化开发框架，通过扩展定义的JSON文件来定义此扩展的名称、作者、类型等配置信息，通过静态文件实现功能定制。

完善的消息推送机制

通过消息推送（也就是Hook）可以将系统事件延展到其他集成系统中，以此完善工具功能，提高平台工具流程的完整度，并且可以简单实现与其他系统的实时信息同步。

通过这三种对于扩展的技术支持即可满足绝大部分对于产品的定制化需求。好处就是DevOps平台工具不需要为不同客户定制化开发不同版本，对于产品的开发企业可以极大的降低产品本身的维护复杂度，可以将产品的研发团队以及支持企业客户的技术支持团队解耦，降低管理成本

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

当然如果有一些特定用户无法通过之前的三种手段实现研发流程的全覆盖，那么就需要终极手段-定制化开发了。其实这种情况也不少，例如：一个大型企业中有几千软件研发人员，那么他对于DevOps平台的要求可能会更多，他们会希望能落地所有流程，能和公司其他管理工具做深度集成，希望平台套用企业统一样式等等。

如果产品设计上能做到以上四点，那么可以说这款DevOps平台产品具备了一个比较优秀的维护与扩展能力。

DevOps工具链的终极形态构想

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

• 流程管理：主要提供给利益干系人、管理者进行信息查看和流程操作使用，此功能需要有对外展示页面。但是开发团队只需要使用轻量化的IDE完成所有操作即可，所有信息与操作均可以在IDE上直接、精确的显示与操作。

• 后台服务：提供包括代码管理、流水线管理等其他核心服务

• 度量：可以根据任意维度显示所有与开发活动相关的数据，包括流程管理数据、工程管理数据、行为数据（例如开发人员的代码开发习惯，开发时长，代码质量分析等等）。并且可以快速的形成报表进行展示。

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

1. 环境：

   1. DevOps平台工具：简易部署，便于维护

   2. 开发IDE：解决所有IDE环境依赖配置复杂困扰，提供协同开发优秀解决方案，强大而不复杂的DevOps平台工具深度绑定

   3. DevOps自动化流水线运行环境：自助式的容器化流水线运行环境

   4. 应用运行环境

2. DevOps组件：

   1. 丰富的DevOps功能接口

   2. 通用化JS集成框架：方便开发者定制化DevOps集成功能

   3. 实时的研发数据动态收集功能

3. DIS（DevOps Integration Service)

   1. 易于配置的集成服务

   2. 兼容主流DevOps工具集

   3. 开源化运营，便于使用者的二次定制化

如对企业DevOps一体化平台建设感兴趣及合作，请添加微信：

本课程主要讲述敏捷项目管理理念与方法实践，主要介绍规划与设计中的影响地图、用户故事地图，敏捷需求管理以及团队与协作；并以华为云敏捷项目管理企业实践，阐述了敏捷项目管理的理论、方法与模型。

本期训练营第三模块【协作模块】邀请到华为云DevCloud 高级产品经理 张军胜老师带来3小时大时段课程分享，主题是《敏捷项目管理实战》

6月7日（周二）和6月8日（周三）晚上19:00-20:30，线上直播，扫码立即报名，精彩内容，不容错过