企业DevOps一体化平台建设思路

当前DevOps工具发展情况

自从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平台产品都是以项目 / 系统 / 团队范围内的研发管理，但是由于很多企业的不同产品间是存在耦合的，很多时候需要不同系统协同开发与发布，而很多DevOps平台产品对跨系统支持的并不好。正确的做法应该是从管理维度上平台工具应该覆盖软件研发的所有过程，从工程维度上来讲，要具备软件发布版本上的协同研发管理。
• 可度量设计缺失、数据分散：有些DevOps平台的研发数据分别存储在不同功能模块中，各个模块数据没有联系，这种情况尤其体现在基于开源产品的封装式产品上；有些则无法简单的定制化度量报表。

  DevOps工具链优化案例

  项目为基于XX平台定制一整套从需求到交付生产制品的全研发流程落地管理规范，首先我们在不进行定制化开发的情况下，制定了一整套基于现有功能的版本管理方法，当然这里需要进行较多的手动信息整理与维护，然后在试点团队中验证这种方法是否可以帮助团队实时掌握自身版本以及协同开发系统的指定版本信息，然后再将此功能固化到XX平台产品中，在此过程中也发现了很多工具无法支撑整个过程的情况，这也是我们对于工具提出的改进建议依据。
  最终形成了以版本为信息为核心的统一协同管理，通过版本可以查看和操作整个版本研发过程相关的需求，版本分支，流水线运行，环境部署结果，测试结果等信息。同时通过各系统间的版本关联，可以查看其他相关系统的版本研发进度与相关详细信息。
  通过这种方式，即验证了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. 开源化运营，便于使用者的二次定制化