普元DevOps 5.3 产品研发发布

4个月前

普元DevOps5.3新增64个功能特性、优化了26项体验,使普元DevOps平台性能实现了较大提升。

转载本文需注明出处:微信公众号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很多时候被诟病实施效果不明显,因为什么?

如何把握版本范围?



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

售前交流的建议: 来自这方面的需求很多,对团队来讲,则需要很好的鉴别能力
项目实施的积累: 这个一般没有疑问,是必须纳入到后续版本的一部分需求
核心特性的巩固: 这个取决于产品定位,就像我们的定位是企业级生产线,那就必须满足企业的常见流程、中间件要求,并不断升级优化,要在这些特性上做到行业领先
竞争对手的压力: 尤其一些pk时的丢分项,或者对手的加分项,会是我们重点斟酌是否要纳入的需求来源

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



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

单职能部门承建,缺少高层推动。因涉及角色较多,如果只是为某个部门服务,平台是很难形成规模效应的
工具堆积,缺少流程与规范。单纯的工具链打通只是解决了统一工作台的问题,但是工件之间的关系并不能有效关联,进而很难做整体的分析优化
一味追求快,对安全、质量考虑较少。企业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版本中,最终形成如下的平台能力矩阵:



二、对研发过程的思考

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

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

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

自我学习,版本到了一定程度,不再是简单的对手产品分析就可以制定方向的,更多的是自身的学习积累后的一些思考
时间投入,无论是甲方乙方,负责产品的人事情都相对较杂,如何保证产品需求的不断纳入,是对产品经理的一个挑战,有一些时候,我们甚至发现backlog没有了
取舍思路,产品的缺陷、待优化点会很多,优先级的不断调整则是摆在小团队面前的最大难题
代码深入,可能有些互联网的产品经理更聚焦业务过程,但是对于普元这样的中间件厂商,产品经理越深入技术,则会给产品带来更多的内在进步

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

业务的理解,比如前端与后端人员的分离,虽然技能更专业,但对整体业务需求的把握,总体上还是不如以前从前做到后的工程师
开发团队的自我责任感,纯测试团队在乙方会越来越少,开发人员的自测会变得更重要

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

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

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

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

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

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

三、下一版本的想法

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



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

测试管理之前多数是和其他厂商集成的,新版本会自带一定的支持
自动化测试则主要支持前端自动化以及API自动化
与gitlab、jira等工具的权限做映射管理

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


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

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

COMMENTS

需要 后方可回复
如果没有账号可以 一个帐号。