首页>>互联网>>DevOps->普元devops怎么样?

普元devops怎么样?

时间:2023-12-07 本站 点击:0

导读:本篇文章首席CTO笔记来给大家介绍有关普元devops怎么样的相关内容,希望对大家有所帮助,一起来看看吧。

普元DevOps 5.3 产品研发发布

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

一、5.3版本的主要特性

二、对研发过程的思考

三、下一版本的想法

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

如何把握版本范围?

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

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

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

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

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

一、大型项目群管理

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

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

二、个性化的跟踪看板

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

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

三、更全面的部署能力

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

有人用过普元eos的吗?用这工具开发的工作有没有必要待下去

利益相关:普元现员工。

首先说,普元不只有EOS,从企业级平台的角度,还有BPS、ESB等16款产品和解决方案。

从EOS平台使用者的角度,不客气的说,EOS在Eclipse方面的应用在国内是领先的,有朋友曾经通过研究EOS的设计和原理,获得了在工作方面的很大帮助。

所以,我的看法是,使用任何工具和平台,是否能得到个人的技术成长,在于是否能够从平台的使用中提升和总结,不是把平台当工具,而是把平台当教材,想一下如果自己做一个平台,数据结构如何设计,分层体系如何构建,诸如此类。

从技术路线来说,做企业级平台的,跟进最新技术最紧密的,普元是其中之一,普元正在对EOS进行微服务框架和容器云的升级和提升,并且应用在BPS方面的优势进行DevOps的设计和实现。

并且,普元正在进行新一代的数字化企业云平台的开发,目标是发布一个可用于私有和公有环境部署的Paas平台。感兴趣或者想学习相关技术,可在百度中搜EAII了解。

RT:想问下各位从事互联网对普元EOS有自己的了解和认知的同行们,希望能给我说说这个东西的前景、局限

普元在2016年研发的云平台中融合了微服务、容器和DevOps、元数据相关技术,已经不是原有的EOS所能涵盖的技术范畴。这一平台的研发文档和设计文档、会议纪要,在这个公众账号(eaworld)上都可以找到,算是开了企业级软件研发开放的一个小小的先例。

需要补充的是,普元现在不是只有EOS或BPS,而是覆盖了SOA、大数据和云计算三条产品线约16款产品,以及一些行业解决方案。

关于EOS的设计理念和原则可以参见EOS设计者在知乎的回答

作者:焦烈焱

链接:公司要引入普元公司的EOS框架,对于公司未来的技术发展会有什么影响? - 焦烈焱的回答

来源:知乎

著作权归作者所有,转载请联系作者获得授权。

今天刚看到这个提问,作为EOS的设计者回答一下,不敢说客观,主要说说设计时的思考。

1. EOS 的初衷是解决企业级JAVA开发的一些共性问题,虽然已经有SSH等很多框架,但是在应用过程中有很多非功能需求并没有涉及,尤其是分布式环境下,以hibernate为例,如何实现多服务器配置文件的同步,如何做集群状态下性能的监控,开源软件都没有解决。由于我们有很多大型客户的经验,例如华为 工行,于是就把很多类似的经验体现在产品中。EOS 并不解决业务逻辑快速开发的问题,而是解决企业环境下非功能需求的问题,提高软件的可管理能力,尤其是大规模的软件开发,这也和我们的经验相关。同意 何明璐 所说,目前市面上的快速开发平台解决复杂 ERP 系统的快速开发都不可能,所以 EOS 在设计之初考虑解决的就是解决非功能需求的实现,而不是业务逻辑的快速开发。

2. 基于JAVA做应用架构的方式很多,这也是有很多开源软件的原因,仁者见仁智者见智,EOS既然试图解决JAVA的应用架构,就不可避免的要有自己的理念,这些理念未必大家都认同,这也是我过去比较头疼的问题,也是开发者争议比较多的问题。不像工作流,大家对他的认识和定位比较清晰,比拼的是功能和性能,普元的工作流性能非常强,功能上对外接口特别丰富(真的不是自卖自夸),所以得到很多认同。

3. EOS中争议最大的是拖拽式开发业务逻辑(也就是说的可视化开发),其实拖拽式开发大家并不反对,例如拖拽式进行数据建模,但拖拽开发业务逻辑就未必是好事了。我们设计时即可以用拖拽式开发,也可以用spring bean的方式写代码开发业务逻辑。图形化(拖拽式)开发业务逻辑,最大的用处是处理异步的逻辑,例如调用一个 WebServices,同步调用时如果被调用方很慢,当前的线程也会被挂死,异步就没有这个问题,至少还能够超时释放(这里比较复杂,就不细说了),但是异步的代码写起来很复杂,要写成回调方式,这样代码的可读性就非常差(试想用回调方式调用 3 个 WebServices的代码结构),这样用图形化就比较简单,执行时会变成异步的。

4. 使用 EOS 时,最好根据自己的情况制定规范,因为 EOS 在做产品的过程中要考虑很多情况,但在企业中面临的问题就固定一些,例如不喜欢拖拽式开发业务逻辑可以不用,不要因为普元的培训时讲了这个方式就一定使用,也可以和普元的工程师探讨一下。使用一个框架的时候,技术团队可以多从设计原理、架构、面临问题的角度考虑一下框架的设计初衷,提高对技术的掌握。我的很多合作伙伴(例如工行、建行)他们都深入的掌握了 EOS,并和他们自己的实际结合了起来,变成了他们自己的框架,这一过程中他们的技术也有了很大的提高。

5. 做为设计者,EOS是一个在设计过程中让我们很纠结的产品,主要原因是他试图解决的问题比较复杂,也很广泛,而对于这一问题的解决方案又有很多种,尤其是有很多开源软件,无法穷举。在普元后续产品的设计中,我们吸取了这一经验,把要解决的问题更加聚焦起来。

6. 普元未来还是解决我们在大中型企业信息化的技术架构问题,但设计思路上更加聚焦。在 EOS、流程 之后,又有了 ESB、数据集成、数据质量、IaaS 等产品,目前的数据集成产品,是基于最流行的开源软件 Kettle,但是我们的重点是解决 Kettle 没有解决的调度问题(例如每晚有成千上万个作业,作业之间可能有先后持续,作业失败了怎么办,如何监控等);目前的 IaaS 产品基于OpenStack,但是我们解决了 OpenStack 在企业私有云下的管理体系问题(例如小网段、心跳检测、高可用组件自身的高可用、多维度管理)。数据治理产品重点解决数据集成后,数据的血统分析和影响度分析,形成数据地图。

如果要了解普元的官方信息,可以到普元官网了解 

普元是国内领先的软件基础平台与解决方案提供商,主要面向大中型企业、政府机构及软件开发商提供SOA、大数据、云计算三大领域的软件基础平台及解决方案,用以满足上述组织信息化建设对关键技术的需求,帮助上述组织的业务在云计算和移动互联时代向数字化转型。普元系国家规划布局内重点软件企业,并是国际标准组织OASIS成员、SOA国际标准SCA/SDO的主要参与制定者、全国信标委SOA分技术委员会SOA与Web服务工作组副组长单位、全国信标委云计算工作组成员单位。

普元专注于软件基础平台领域,具有分布式计算、服务构件技术、可视化技术、业务流程管理、内存计算、企业移动计算、数据治理等核心技术,拥有多项国家软件发明专利,同时是中国少数通过国际软件能力成熟度模型集成(CMMI)5级认证的软件厂商之一。

在中国市场,普元产品已经在金融、电信、电力、军工、能源、政府、制造、物流等多个行业的数千关键应用上得到验证,拥有中国工商银行、中国建设银行、中国交通银行、国家开发银行、中国银联、中国移动、中国电信、中国联通、国家电网、神华集团、航天科工、中航工业、海关总署、民政部、阿里云、德邦物流等超过数百家大中型用户。在海外市场,通过与华为公司合作,普元产品已销往加拿大、巴西、日本、科威特、南非、也门、印度、荷兰、泰国等近40余个国家。

普元重视构建合作共赢的商业生态,与华为、亚信、太极股份、远光软件、亿阳信通、高伟达、南天、中科软等数百家大中型软件商深入合作,公司在北京、上海、广州、成都、西安、武汉、南京等地设有分支机构,为各行业用户及合作伙伴提供高品质的技术服务,全面保障产品成功使用。

普元先后成功承担了多项国家、省部级重点科研课题及产业化项目,如国家发改委软件产业化专项、国家发改委云计算专项、上海科教兴市重大科技攻关项目等,普元系列产品多次荣获上海市科技进步奖、上海市优秀软件产品等重要奖项。此外,普元是国家博士后科研工作站、国家高技术产业化示范工程单位、国家云计算服务创新发展试点示范单位。

普元由多位已取得卓越成就的企业家和科学家携手创立,汇聚了一流的计算机技术专家、管理精英和各类专业人才。公司总部位于中国(上海)自由贸易试验区(张江高科技园区)。

结语:以上就是首席CTO笔记为大家整理的关于普元devops怎么样的相关内容解答汇总了,希望对您有所帮助!如果解决了您的问题欢迎分享给更多关注此问题的朋友喔~


本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若转载,请注明出处:/DevOps/16499.html