普元DevOps 5.3 产品研发发布
发布网友
发布时间：2022-08-25 10:53
共1个回答
热心网友
时间：2024-11-02 10:08
普元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的所有独立包，现在终于理解了）
