DevOps实践分享：4个实施步骤与6个关键设计

本文介绍了普元DevOps平台在金融行业实施落地的常用方法，以及在项目管理，代码管理，构建管理，制品管理，部署管理等模块针对一些典型客户场景的关键设计。

目录

01 平台简介‍‍

02 实施方法‍‍‍‍‍‍

03 关键设计

平台简介‍

1. 普元DevOps定位

普元DevOps平台以质量和安全为基础支撑保障，通过工程化的手段，打造一条覆盖从需求到研发、测试、部署、运维的软件生产全周期的IT生产线，帮助企业提升IT系统研发效率，快速响应业务需求，并通过度量分析、风险预判，持续提升IT运营能力。

2. 普元DevOps集成‍‍‍‍‍‍‍‍‍‍‍‍

既然要实现软件研发的全生命周期的管理，自然不可避免需要对企业软件研发交付的各个阶段进行一些集成方面的工作。这里从纵向和横向两个维度来看。

横向的话实际上是从全生命周期过程中，整个软件从需求提出，到研发测试，到最终上线，它涉及到了不同部门和角色，不同人员之间的一些协作。横向主要是为了打通跨部门，不同职责的人员之间的壁垒，通过流程驱动的方式，让各部门能高效的协同合作。

纵向维度主要是从软件需求的管理，项目过程的管理，开发代码的管理，测试过程的管理，到后续持续集成和持续发布，再到验证及最终上线，会涉及到不同的工具链。纵向主要是为了打通了工具链的串联，以实现数据和流程的打通。

3. 普元DevOps价值‍‍

在通过集成过程打通各部门壁垒，打通工具链串联之后，最终实现数据和管理流程的打通。同时通过度量的方式帮助管理者进行过程的优化，这是我们的一个最终目标。

我们在DevOps在实施过程中通过解决如下问题以创造客户价值。

管理前移：通过流程数据的打通，可以提前感知项目存在的风险，项目进度是否有延迟，质量与预期的目标是否有偏差，帮助管理者能更早的发现问题并介入处理，以便能更早的规避风险。

全链路追溯：通过数据流程的打通建立从工作项-代码-构建-制品-发布-实例运维的一整条链路信息。以便发现问题时能很方便的进行链路追溯和问题排查。

量化评估：打通流程和数据之后，可以基于报表相关数据对各个阶段的工程效率进行度量，也能更好进行资源分配。同时可以更准确评估完成需求需要的时间，以便合理的制定开发计划。

自主掌控：对代码源头，编译过程，发布过程进行管控。

多架构适配：支持各种技术栈应用的编译，编译环境管理，支持不同的中间件应用发布。在一个统一的平台上形成完整的资产和信息链。屏蔽一些差异化，通过相对标准的配置就能进行管理。

驱动协同：这里不仅仅是开发和运维了，它是完整的，从需求，开发，测试，运维。并涵盖质量与安全。这也就是之前提到的横向打通部门之间的壁垒，实现高效的驱动协同。

02‍

实施方法‍‍

1. 实施过程总览

通常，会将DevOps实施过程分成如下四个步骤。

调研分析：‍‍

1) 组织级现状调研

基于需求范围对企业IT管理流程和规范进行调研，如项目管理，需求任务拆分，缺陷管理，应用提测及投产流程，代码库分支管理策略等。同时，需要对企业的网络架构及管理规范进行调研，结合企业已有平台（代码库，制品库等）部署情况，合理的设计DevOps平台的部署架构。

2) 试点选择与调研

试点项目选择需要基于企业应用特点，选择最具有代表性的项目（应用架构具有普遍性，如微服务项目等）。根据试点项目应用类型梳理接入DevOps关键问题点并进行调研。

3) 范围梳理

根据上述调研的情况编制调研分析报告，结合需求范围与调研的结果合理的规划后续的实施范围及方案。

制定方案：

1）平台部署方案

根据之前的调研情况以及与运维的沟通，制定平台的部署架构。梳理需要部署的应用以及资源信息（主机资源或云上资源信息，高可用，存储，CPU，内存等），以及应用之间的交互方式及端口，以便开通网络策略。

2）技术验证

搭建完平台环境之后可以进行试点项目应用的验证，试点项目工程的CI，CD验证等。

3）平台建设方案

在技术验证的过程中，同步梳理项目的建设目标，集成方案（单点登录，应用服务器，容器云等）。

实施落地：

1）建立规范

根据试点项目的应用类型，梳理对应该类型应用的CI，CD相关规范，结合代码库管理规范与制品管理规范等配置对应的流水线模板，建立对应的最佳实践。

2）平台定制

在验证过程中，根据情况扩展工具集。基于需求范围同步完成其他如单点登录，容器云等平台的集成开发。

3）试点接入

在建立对应应用类型的最佳实践之后开始对同类型项目试点进行宣贯和培训，以便能够快速接入。

运营推广：

1) 实施推广

建设推广运营团队，制定平台运营推广指南，建立标准规范体系，提供技术支撑，加强项目组的能力建设。

2）持续优化

在推广过程中持续与项目组沟通，获取反馈信息，持续优化DevOps平台。

2. 落地方法与策略

迭代演进

DevOps建设不可能一蹴而就，需要结合平台特点、项目需要、以及企业自身的组织能力，形成阶段性目标，采用迭代演进的方式，有重点分步骤的建设。每次迭代必须有明确目标、工作清单、交付物。

自主掌控

在DevOps建设过程中，需要重视企业自身IT队伍的培养，确保自主掌控，实现人员能力和组织能力的双落地。IT部门应该深度参与项目实施过程，与DevOps实施人员共同组成团队，承担具体的实施任务以及后续的运营推广。

03‍

关键设计‍‍‍‍‍‍‍

1. 项目管理‍‍‍‍‍

工作项概念模型‍

我们将不同的项目管理模式定义成不同的项目模板。项目模板包含人员角色模板，菜单模板和工作项方案等。

Ø 角色模板

人员角色模板定义了一类项目管理模式中涉及到的人员角色。不同的人员角色有不同的权限配置。如项目中有项目经理和需求分析员等人员角色。系统中有系统开发负责人，开发人员，测试人员，配置管理员，运维人员等角色。

Ø 菜单模板

菜单模板定义了一类项目管理模式中涉及的功能菜单。如系统下对应用程序做构建和部署，生产上线也是以系统为单元。在项目下不进行构建和部署则不需要对应功能菜单。

Ø 工作项方案

工作项方案定义了一类项目管理模式中涉及到的工作项管理。如项目中需要对业务需求拆分的需求条目进行管理，系统下需要对条目拆分的系统需求，开发任务，缺陷等工作项进行管理。不同工作项对应的页面及属性也不同，工作项状态流转过程也不同。

项目模板的能力用以应对企业项目管理的差异化需求。同时借助项目之间关联的能力实现项目与系统的关联以及跨项目的工作项拆分。

2. 代码库管理

通常，代码库按系统分组，系统下的每一个工程都有一个或多个独立的代码库，它们通常独立的进行编译和部署。

如scm系统下的lmp工程前后端独立开发部署：scm/lmp-portal.git，scm/lmp-server.git。

代码分支策略-多分支并行

这是一个代码分支管理策略的示例（系统存在多个项目的需求并行开发，测试，上线）：

客户需求：

Ø 既希望版本可控，又希望简化项目组工作量。

Ø 单项目多批次上线：同一个项目可能分多个批次上线。

Ø 系统下多项目并行开发：开发、测试和投产都是按项目管理，但为了简化运维工作，希望在同一天上线的多个项目合并投产一次。

Ø 计划调整：计划上线的特性可能临时调整，不上线的代码不投产。

大家也能看出如上第四点中计划上线的范围变更所带来的问提，系统下工程存在多个项目的需求并行开发，同时规划好要投产的代码要提前进行合并测试。

但临上线之前的范围变更，并没有足够的时间进行重新合版测试。最后的结果只能是投产的版本与测试的版本不能完全一致。

在面对这种问题我们都会解释这种临时的变更是不合理的，是不符合管理规范的。但这么显而易见的问题，客户又怎么会不知道。只是日积月累，有些问题很难一下子就改变，但在当下要做的是结合已有的能力尽可能的去规范化，去简化这些流程。

代码提交规范

通过代码提交和任务关联的方式，可以解决代码库策略中的部分问题，如基于系统需求去筛选代码进行cherry-pick。

我们提供了Eclipse和IDEA的插件，开发人员可以在开发工具上就能处理自己的开发任务。同时提交代码时可以选中代码对应的开发任务，这样会自动生成代码提交的信息，并将代码提交记录与工作项任务关联。这样在系统需求和任务中就能看到提交代码的记录。

3. 构建管理

最佳实践-应用构建模板

DevOps提供了涵盖代码，工具，构建，部署，测试等类型共计80+个原子任务，同时提供了动态表单加静态脚本扩展原子任务的框架以满足企业持续集成和持续部署的需求。

针对企业不同的应用类型，我们通过原子任务的编排配置及参数抽离建立了不同的应用构建模板，以供同类型应用可以导入执行，以达到统一规范，建立应用构建最佳实践的目的。

最佳实践-云上构建

云下构建过程中，如果存在系统公用引擎的情况，可能会产生一些问题。如一些构建工具的多版本及全局配置问题（编译环境隔离）。

DevOps平台提供了构建引擎节点在云上动态扩展的能力，可以实现节点按需扩展（一个构建任务对应一个pod）。

我们根据微服务应用编译用到的原子任务，去配置pod template，pod template中包含了微服务应用所用到工具的容器，同时包含一个额外与jenkins master交互的jnlp容器。在微服务应用执行构建时，会自动调用云环境，用pod template中定义的容器配置去创建对应的pod来执行整个构建过程。

4. 制品管理

制品库管理

除了制品库管理需求，企业本身还有自己的三方库管理，通常会使用代理外网或离线同步的方式管理第三方依赖。同时会使用独立的库管理企业自身产出的一些依赖。

制品库一般按系统和环境划分，不同的环境使用不同的库，通常区分开发，测试，投产库。开发，测试库制品通过编译产生，生产库制品通过测试库中测试通过的制品晋级获取。

制品目录结构

除了按环境分库管理，对制品目录也会建立规范要求。如在测试环境和生产环境使用基线（投产窗口）作为一级目录（测试环境可以加上提测次数标记）。

基线下可以按应用模块划分，每个应用模块都应该是一个独立部署的单元。

config目录存放变更的配置，app目录存放变更的应用程序包，data目录存放变更的数据包（如升级sql，回滚sql等）。

制品元数据

通过关联对象的打通我们基于制品汇总了关联信息，同时我们在多个功能模块中都可以对全链路信息进行追溯。

Ø 工作项：可以查看制品中新增部分所对应的需求，任务以及修复的缺陷等。

Ø 代码库：可以查看制品对应的代码库，分支，commit等信息。

Ø 构建：可以查看制品是从那个构建定义的那一次执行产生的。

Ø 发布：可以查看制品是否已经被部署到具体的环境。

Ø 质量：可以查看制品的代码扫描的结果信息。

Ø 依赖：可以查看制品的第三方依赖及其license信息。

Ø 安全合规：可以查看制品中依赖的漏洞信息和license合规（不允许商用等）信息。

制品晋级

质量和安全在整个软件研发全生命周期中是无处不在的。因此对于检测的执行过程是可以分散在不同的功能模块中，但管控不应该是分散的，我们应该基于特定的管理流程对我们需要执行的检查结果进行统一管控。

Ø 质量配置：

指标管理：对不同工具的检查结果指标要求进行定义。

策略管理：检查结果校验的后处理逻辑，如邮件通知，自动创建缺陷，工单审核等。

清单管理：汇总指标和策略配置并与具体的系统进行关联。

Ø 数据关联（建立检查结果数据与制品关联）：

代码扫描：代码检查的结果信息。

制品扫描：制品依赖的漏洞和license合规的信息。

容器扫描：容器扫描的漏洞信息。

自动化测试：测试环境自动化测试的结果信息。

Ø 统一管控（在制品晋级流程中基于质量和安全检查结果信息进行管控）：

晋级申请：测试通过的测试制品库基线目录发起晋级到生产库的流程。

晋级审批：基于质量配置指标自动检测制品关联的结果信息，也可触发人工检查流程。

5. 部署管理

部署流水线配置

同构建一样，部署也是采用的原子任务编排的方式实现，如一个发布流水线用到数据库备份，数据库脚本执行，websphere应用部署等原子任务来实现应用及其数据的备份和部署。

应用部署原子任务示例

这是一个websphere应用部署原子任务的例子。主要想说明的是部署不单单只是一个部署脚本的执行，我们会有针对应用发布的一些流程进行管控，如全量部署，增量部署，应用备份，应用回滚等。

应用部署规范

基于平台提供的能力，根据应用部署的规范要求，通过流水线配置将同一类应用的部署过程模板化，并保证不同环境基础设施的一致，这样才能保证同一条流水线在不同环境中都能正常使用。

6. 生产发布

平台部署方案

一套平台的部署方案相对简单，通常会将平台部署到生产，然后打通到开发测试点对点的网络即可。

但部分企业对生产环境的网络打通有严格的管控，同时运维人员使用的平台需放到独立的环境中。上图就是两套DevOps环境，使用单向数据同步的部署方案。打通生产DevOps单向访问测试区DevOps的网络，用以同步所需的关键数据，如项目，系统，流水线等。打通生产制品库单向访问测试区DevOps的网络，用以同步生产发布所需的制品。