普元DevOps 5.3 产品研发发布

转载本文需注明出处：微信公众号EAWorld，违者必究。

引言：

普元DevOps5.3新增64个功能特性、优化了26项体验，其中，大型项目群管理能力、全新报表能力、动态任务看板、部署能力增强、第三方工具升级、平台性能优化6大关键特性，使普元DevOps平台性能实现了较大提升。

目录：

一、5.3版本的主要特性

二、对研发过程的思考

三、下一版本的想法

一、5.3版本的主要特性

首先说说我们的产品发展，每个版本在定义之初会有一个核心目标，围绕核心目标再去对特性分解和制定优先级。

• 1.0版本，我们是追着热点概念来，容器云、微服务、DevOps同时开展，投入很大，但种种原因，效果并没有达到预期。

• 5.0版本，更像是一个重构版本，经过1.0版本的市场尝试，我们知道什么是重要的，什么是紧急的，什么是普元所在的企业市场所需要的。

• 5.1/5.2版本，是一个敏态与稳态共同支撑的双模版本，正值很多企业的数字化转型阶段，所以版本里既有敏捷的项目管理、也有瀑布的推进模式，能力上相对则更偏敏捷一些。

• 5.3版本，则在一次次实施过程中，充分认知了企业DevOps市场的特点与难点，进而形成了以企业级中间件支持、企业级项目管控模式等为重心的平台建设。

如果这里有产品经理，可能会问，如何来考虑新版本的需求范围？

如果这里有DevOps产品经理，可能会问，DevOps很多时候被诟病实施效果不明显，因为什么？

如何把握版本范围？

基础软件市场向来是竞争激烈的，但是合理运用好这个市场氛围，会是产品经理的一大利器。对于一个发展中的产品版本，需要的来源一般包括四块：

1. 售前交流的建议： 来自这方面的需求很多，对团队来讲，则需要很好的鉴别能力

2. 项目实施的积累： 这个一般没有疑问，是必须纳入到后续版本的一部分需求

3. 核心特性的巩固： 这个取决于产品定位，就像我们的定位是企业级生产线，那就必须满足企业的常见流程、中间件要求，并不断升级优化，要在这些特性上做到行业领先

4. 竞争对手的压力： 尤其一些pk时的丢分项，或者对手的加分项，会是我们重点斟酌是否要纳入的需求来源

为什么很多企业DevOps建设效果不明显？

DevOps在实施后，很多人会觉得效果不明显，产生这个的原因同样有这么几点：

1. 单职能部门承建，缺少高层推动。因涉及角色较多，如果只是为某个部门服务，平台是很难形成规模效应的

2. 工具堆积，缺少流程与规范。单纯的工具链打通只是解决了统一工作台的问题，但是工件之间的关系并不能有效关联，进而很难做整体的分析优化

3. 一味追求快，对安全、质量考虑较少。企业IT系统的交付，安全是重中之重，单纯的自动化驱动只能解决部分问题，对于最卡壳的并没有实质解决。

技术有限，平台级设计不足。DevOps是一个持续的建设过程，周期也相对较长，如果只是短暂的考虑眼前的工具、管控，很可能在后续的发展中成为瓶颈。

回到标题，在这里和大家分享我们在5.3版本里的六个特性：

一、大型项目群管理

项目群是为了实现更高战略目标，对一组项目进行统一协调管理，日常工作则仍在各个项目内进行。

比如最近普元来了一个支持IPv6的需求，全线产品都需要做，此时就需要一个项目群来统一协调，制定大里程碑，组织驱动所有子产品按目标执行。在金融、电信等行业此类组织特征尤其显性。

所以在项目群的特性里，需要提供对多个项目统一协调，通过主项目与配合项目的设置，以及里程碑的跟踪，有效协同。

二、个性化的跟踪看板

工作项看板的核心是做到千人千面。首先，用户可自由挑选列表模式、详情模式、或泳道模式来做展示，且不管哪种模式，都需支持快速过滤、排序。

再者，因为往往客户是敏捷与瀑布并存的，所以对于固定版本驱动和冲刺计划驱动，都需要友好支持。

还有一个重要特性是工作项状态流的管理，拿泳道模式来说，每个项目需支持自定义配置泳道数量、泳道顺序、泳道可承载工作项、泳道承载工作项状态等：

三、更全面的部署能力

部署功能一直是我们DevOps的重点，尤其对于企业级中间件的各种策略的部署支持。在上一版本的基础上，我们补充了对于专有软件发布的支持（比如EOS增量发布、某厂商ESB发布、某厂商机器学习模型发布等），让产品在企业市场适应性更佳。

再一个，在各类应用部署过程中，不仅仅只是正常流程的处理，更需要对异常情况充分考虑，比如websphere上应用部署，备份、强制覆盖、是否重启等都需要进行开关控制，且部署后需考虑应用的回退、卸载等运维能力：

websphere上的应用部署

四、三方工具的升级与打通

在项目的不断实施中，大家都会发现一些三方工具的缺陷或能力不足，有时我们会自己来弥补、有时我们会选择绕过去。 5.3版本中，我们对之前已经发现问题的三方工具，进行了可升级评估，部分采用版本替换模式，部分则采用版本兼容模式：

• 比如jenkins： 目前升级到了2.164.2版本，核心问题在于jenkins低版本的假死现象比较严重，且部分插件的不稳定

• 比如nexus： 目前升级到了3.16版本，前序版本对于介质空间压缩效果很一般，独立运维要求较高

• 比如gitlab： 则是采用同时支持8、9、10版本的方式，当然会给开发带来一定难度，因为其API的不兼容

五、丰富的报表统计与分析

5.3版本对报表进行了重新梳理，从任务、代码、测试、构建、部署维度切分，通过跑批，计算数据状态和趋势，做更深层次的分析。

基于上述的一系列报表，以及持续的运营数据，及时得到项目风险提示，指导PMO或项目经理有效干预。

六、非功能特性的集中优化

性能、可靠、体验是DevOps最重要的三个非功能特性，新版本中，拿性能为例，我们并不是那种一味的通过压力测试工具来驱动，个人觉得很多非常规场景下性能问题才容易暴露，所以我们更多的是结合实施情况做了一些定向优化，主要包括：

• 分布式锁的重新设计：原先锁定时间的固化等，调整成前序可设置，让一些特殊场景可以自行控制，并结合超时、重试等手段解决一些非常规问题

• 升级序列化能力：这个是原先架构设计的一些原因，序列化这块没有统一，此版本将jsonlib等性能一般的框架移除

• 修改Jira认证模式：jira的basic认证是我们之前的使用方式，但是在实施中发现其性能远不如session模式快，所以将其替换成了session模式

• 返回数据量裁剪：尤其在多系统发布流水线上，因为返回数据较多，使得网络占用、前端解析都会有一定延迟，此次对关键API进行了统一review，裁剪冗余信息

• 配置日志数据存储与保留策略： 平台中需要汇聚来自各模块的日志，并对日志中的敏感信息进行处理，但随着平台的运行，日志的存储会越来越大，且影响界面append展示，所以除了传统运维的一些手段，本次对日志的存储策略、保留策略进行配置控制，可结合实际要求进行保留（其余转历史）

• 还有像一些报表数据汇集算法、守护进程开关这类调整，不再一一描述

在DevOps5.3版本中，最终形成如下的平台能力矩阵：

二、对研发过程的思考

接着分享下在研发过程中的一些感触，这块没有过多整理，只是将之前遇到的一些问题做了些归纳：

一、团队文化方面，尤其在版本相对成熟之后，对于团队的要求会越来越高，重点体现在产品经理与开发团队身上

产品经理的高要求体现在：

1. 自我学习，版本到了一定程度，不再是简单的对手产品分析就可以制定方向的，更多的是自身的学习积累后的一些思考

2. 时间投入，无论是甲方乙方，负责产品的人事情都相对较杂，如何保证产品需求的不断纳入，是对产品经理的一个挑战，有一些时候，我们甚至发现backlog没有了

3. 取舍思路，产品的缺陷、待优化点会很多，优先级的不断调整则是摆在小团队面前的最大难题

4. 代码深入，可能有些互联网的产品经理更聚焦业务过程，但是对于普元这样的中间件厂商，产品经理越深入技术，则会给产品带来更多的内在进步

开发团队的高要求体现在：

1. 业务的理解，比如前端与后端人员的分离，虽然技能更专业，但对整体业务需求的把握，总体上还是不如以前从前做到后的工程师

2. 开发团队的自我责任感，纯测试团队在乙方会越来越少，开发人员的自测会变得更重要

二、技术能力方面，对产品形态的抽象决定了产品的生命力

开发过程中，我们团队也会抱怨现在的开源软件太多了，每个设计思路都不太一样，甚至同一个开源软件的不同版本都差别很大，使得DevOps这样的产品变得越来越难做。

这一点确实对团队的挑战很大，就拿jira和zentao的集成来讲，将这两者的模型抽象成一套非常痛苦，一个重在扩展（什么都可以自定义），一个重在适应国内项目管控（提供三套驱动模式），类似的工作我们需要很多投入，甚至多遍重构。

三、产品管理方面，传统的流程管理+迭代的演进思路

我们的每次版本推出，都对我们实施的工程师是一个巨大挑战，新的功能，新的问题。从管理流程上，我们还是保持着修订版+补丁的方式，以前有一段时间想过快速迭代升级，后来发现这种事情只适合To C，To B基本不现实。

不过我们还是会遵循迭代的演进思路，快速修复，减少版本周期。同时我们在版本的无缝升级上花了很大心思，每次变更（尤其数据字段），都会提供对应的全量与升级两套脚本，使得现在5.2的客户可以快速升级到5.3，工作不难，其实就是一种产品管理与团队习惯（以前看visual studio内部结构时，觉得怎么有产品是这么设计的，3.0版本基本上包含了2.0，1.0的所有独立包，现在终于理解了）

三、下一版本的想法

最后也分享下我们下一版本的主要投入，也希望我们的实施工程师，或者有兴趣的各位，能给予一些建议。

简单说明下已确定的部分：

• 测试管理之前多数是和其他厂商集成的，新版本会自带一定的支持

• 自动化测试则主要支持前端自动化以及API自动化

• 与gitlab、jira等工具的权限做映射管理

• 提供独立的运维操作台，便于应用运维人员快速编排与一键发布

精选提问：

问1：自动化测试部分都集成了哪些工具，节省了哪些工作量？

答：目前自动化测试工具的集成在我们即将推出的DevOps5.5版本中会有集成；不过在我们之前较多的客户实施案例中，会有不同自动化测试工具或者平台的集成； 至于说集成自动化测试工具节省哪些工作量，这块其实最节省工作量的是提供了多少的自动化测试用例；如果自动化测试用例能够覆盖90%以上的功能，那么每一轮功能测试只需要夜间批量跑批就OK了。

问2：我听说DevOps落地很难，能说下现在有哪些成功的案例吗？

答：目前普元DevOps产品已经在金融、制造业、运营商、高效、能源、保险、电力等多个行业有落地实施经验。

问3：你们的DevOps的最大优点是什么？

答：这个不能说的太多，不然有自卖自夸的嫌疑： 

1）全生命周期的支持 

2）针对不同客户提供量身定制的DevOps平台适配能力，更能适应企业现状

3）几十个企业级的客户案例验证，对常见的企业级的工具支撑更友好

问4：请问，DevOps5.3产品需要的网络条件必须具备哪些？

答：这个问题比较好；通常客户的开发测试与生产网络是隔离的；针对企业不同的复杂网络模型，我们提供不同的部署方案来支撑。

问5：DevOps5.3在持续自动化方面的能力，目前达到了什么程度？

答：DevOps产品提供了流水线的设计，支持开发流水线、测试流水线、预发流水线、生产流水线，当然可以根据需要自定义不同的流水线；所有的流水线可以自动执行也可以人工介入审批工单；从技术角度来看，目前可以实现一键发布哦（从源代码开始到最终发布到目标环境，比如物理机，虚拟机，容器，多种云平台等）。

问6：DevOps5.3产品的目标，对于交付、运维、微服务应用，目前各自的突出特点在哪些方面？

答：DevOps5.3产品重点关注在运维前面的阶段，对应用的类型无论是微服务还是传统架构，无论是移动应用，还是其它语言，比如C、Python等，都提供了CICD的能力。

问7：DevOps新平台在应用扩展和部署方面有什么好的解决办法？

答：DevOps平台在设计的时候充分考虑了平台的扩展性，可以支持多种类型的编译工具（Maven、Ant、Gradle），在应用类型方面也没有限制，可以支持多种应用类型的接入，部署支持多种异构基础设施（比如物理机，虚拟机，容器，多种云平台等）。

问8：咱们研发团队在开发DevOps5.3或其他软件时，使用DevOps的思想或者工具了吗？

答：我们一直在吃自己的狗粮哦。DevOps5.3的版本就是通过DevOps平台进行项目、需求、CI、CD、流水线的管理的。

问9：Devops对业务流程集成方向是如何把控和处理的呢？还有数据集成。

答：这个确实是个很难通用的工程，目前产品中流程内置较少，这个我们是指企业的实施中不断补充的，平台本身并不想内置太多传统流程的工作，因为这个在企业一般都有系统已经在运行，我们只是给了很多回调接口，以及事件触发机制，便于集成。数据的集成则是视流程来定，以及实时要求。我们还有个想法就是做一些行业的流程模板，比如金融的，我们就有了些总结。

问10：什么样的企业需要DevOps？DevOps能带来什么价值？

答：有一定规模的IT团队就需要DevOps； DevOps带来最大的价值，是先实现IT部门或者IT团队的数字化转型；当然对业务来讲，可以快速试错，快速推新业务，抢占市场啦。

推荐阅读

DevOps落地实践分享（内含四步实施过程，问题解决方案等）

DevOps 5.0版本的150天历程

普元DevOps5.2版本新特性发布

关于作者：顾伟，现任普元信息主任架构师，长期致力于IT技术研究、产品设计与开发、架构咨询等工作，擅长Web、OSGI、CI/CD、服务治理、云计算等领域技术；对DevOps、自动化运维、微服务架构有着浓厚的兴趣。

关于EAWorld：微服务，DevOps，数据治理，移动架构原创技术分享。长按二维码关注！