Devops 1.0 改造 2.0 相关需求点

统一应用入口, 取消平级菜单

现有情况

应用, 应用服务, 应用环境, 应用版本, 都是基于应用的二级附属资源

目前是将此处的二级附属资源同应用同级别队列展示, 在不了解系统的情况下会有迷惑性

且服务管理的需求场景可以做如下考虑:

　　1. 是否需要跨应用的查看所有的服务信息

　　2. 服务信息的更多的场景也是基于应用筛选后对某应用下的服务进行操作

类比到应用环境和应用版本同理

 

 

预期情况

基于以上两点考虑, 建议以应用作为从一而终的统一入口

取消服务管理, 应用环境, 版本管理的全局入口, 移入到选定应用后的应用详情中

在应用详情中以 tab 的形式进行下一级的跳转

版本对多服务的相关限制解除, 清晰展示服务流水进程

现有情况

对版本中的某一环境下的服务存在发版限制, 如下图存在不可更新的情况是因为此服务未在dev环境发布到qa从而导致

qa 环境下无法对此服务进行更新,  而若 dev 环境已经完成更新, 其实各环境都是可以对这个镜像进行更新, 但是基于发布流程

当前版本下的多服务的当前发布环境存在不统一的场景, 页面的扁平设计非常不直观不易于理解当前流水进程

以下逻辑图展示较为清晰, 原理就是 服务B 和 服务A  的进度不统一, 而页面上对版本的某一个环境进行查看的时候相当于越过了服务B 的最新环节去查看他的后面环节

逻辑上必然是不能操作, 但是页面上很难get到具体的原因, 因为只能看到版本指针指向的应用, 且此问题就算是版本指针移动到dev环节也很难看出问题

因为不存在清晰的服务流水进程, 必须基于按钮的显示情况来判断当前流程进程

预期情况

去除版本的环境指针, 取消环境对每个服务流水的限制, 讲限制留存在服务流水本身

每个服务本质就是一条流水线.  流水往下走的时候若未达到条件是无法继续进行

此处以图形化展示将十分清晰不容产生疑问

版本的环境要求取消后, 流水 A 和 流水 B 之间是不存在任何关联以及相关的限制

如下图逻辑图展示

 

非常清晰可见服务A B C 的当前进度以及状态, 如A 环境以完整发布到live, B 环境正在等待发布到 uat, 而C 在 live 发布的时候被审核拒绝

版本环境指针逻辑变更

现有情况, 版本的环境指针指向是为最新的服务发版的停留环境

以下图逻辑图为例, 服务A 为最近一次的构建发布到 live 环境, 因此版本指针停留在 live 环境

 

若最新的更新时间为 服务 C 停留在 dev 环境,  则即时其他服务已经存在更快的环境更新, 版本环境指针依旧停留在 dev 环境

预期情况

按照理想的发版情况, 应用的版本迭代应该保证所有的服务更新到最新环境(live) 后进行封版

因此发版操作的重点是保证所有的服务抵达 live 环境

而各服务的环境存在前进后退的可能性, 此处的版本环境指针逻辑应做如下的处理

区分所有服务中最新发版环境以及最慢发版,

当最新发版环境与最慢发版环境定格在 live 即表示此版本已全部服务以收敛可封版

如下图所示, 一目了然可以识别出当前版本的进行状态

支持自定义流水

现有情况

当前的服务流水是基于应用的环境自动创建

 

创建后的流水内容为高度定制化, 且无法修改具体流水节点内容如下, 此流程的后续调整只能基于应用环境的取舍进行调整

即添加或者去除某一应用环境, 而不支持对具体应用环境内的节点信息进行可选编辑

预期情况

1. 节点可选

基于当前的 1.0 的高度定制化流程中, 可识别到 测试, 发布, 审批三种基础的节点

对此节点可针对各环境进行任意的选择, 如 dev 环境当前无测试节点, 进行追加

或者 uat 环境增加审批节点等

1. 事件告警节点

对节点的丰富度程度进行开发, 支持到事件告警通知, 对通知的类型结构体等信息进行编辑

如支持邮件, 企业微信通知可选, 指定通知人抄送

2. 节点触发器

节点执行前后进行想要的触发, 支持到接口回调或者其他任务调度等功能, 从而丰富流程的功能