普元DevOps 5.3 产品研发发布

普元DevOps 5.3 产品研发发布_第1张图片

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


引言:


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


目录:


一、5.3版本的主要特性

二、对研发过程的思考

三、下一版本的想法


一、5.3版本的主要特性


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


普元DevOps 5.3 产品研发发布_第2张图片


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

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

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

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


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

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


如何把握版本范围?


普元DevOps 5.3 产品研发发布_第3张图片


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


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

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

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

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


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


普元DevOps 5.3 产品研发发布_第4张图片


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


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

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

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


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


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


一、大型项目群管理


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


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


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


普元DevOps 5.3 产品研发发布_第5张图片


普元DevOps 5.3 产品研发发布_第6张图片


二、个性化的跟踪看板


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


普元DevOps 5.3 产品研发发布_第7张图片


普元DevOps 5.3 产品研发发布_第8张图片


普元DevOps 5.3 产品研发发布_第9张图片


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


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


普元DevOps 5.3 产品研发发布_第10张图片


三、更全面的部署能力


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


普元DevOps 5.3 产品研发发布_第11张图片


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


普元DevOps 5.3 产品研发发布_第12张图片

websphere上的应用部署


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


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


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

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

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


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


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


普元DevOps 5.3 产品研发发布_第13张图片


普元DevOps 5.3 产品研发发布_第14张图片


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


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


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


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

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

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

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

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

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


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


普元DevOps 5.3 产品研发发布_第15张图片


二、对研发过程的思考


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


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


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


  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的所有独立包,现在终于理解了)


三、下一版本的想法


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


普元DevOps 5.3 产品研发发布_第16张图片


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


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

  • 自动化测试则主要支持前端自动化以及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:什么样的企业需要DevOpsDevOps能带来什么价值?


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

推荐阅读

DevOps落地实践分享(内含四步实施过程,问题解决方案等)

DevOps 5.0版本的150天历程

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


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


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

你可能感兴趣的:(普元DevOps 5.3 产品研发发布)