【Proposal】应用纬度-调整

[colynn]

Motivation

因为目前『应用』是定义在『项目』之下的， 对于应用的唯一性就不好校验，而且也不太符合 『项目』的初衷，故期望将『应用』也调整为一种资源独立管理，项目只是基于原有应用做一层关联。

notes: 『项目』的设计初衷： 是为了实现资源隔离及权限管理。

Goals

1. 将应用与『代码仓库』的定义分开，存在独立的代码仓库管理；
2. 扩充『应用』的概念（有代码库关联产生，或是三方镜像等）， 可以理解为类似 deployment
3. 应用支持标签用于权限管理（可以理解为更灵活的应用分组）
4. 『项目』可以关联应用（可基于标签过滤可添加的应用）

TBD

1. 『应用管理』包含应用的基础信息，yaml配置、（镜像版本规则、chart版本规则等）？
2. 应用的基础编排定义调整至『应用管理』保留，『项目』内关联应用后可以继承或是修改yaml？
3. 如何解决应用-镜像-代码仓库的关联关系？

Refer To

1. https://www.yuque.com/docs/share/7bfa47dc-9500-4259-8303-2d5ba4937b62?# @sampsonye

[colynn]

新增 "应用管理"的 tab, 如下

@sampsonye @fanhousanbu 可以确认下，你们倾向于哪种方式？

对于 AtomCI的定位， 还是以应用为中心 ，项目只是一个资源隔离的概念（项目消失，环境、资源也就消失）

[sampsonye]

一般我们会遇到两种形式的研发团队
第一种，组织架构与微服务相匹配的团队。整个系统会被拆分成多个“服务”，每个服务由固定的小组来维护，所有针对这个服务的迭代都是串行的
第二种，赶工型团队。系统尚未进行服务化拆分，甚至没有拆分。大多数以项目方式进行迭代，立项后确定团队成员，确定影响的系统范围，项目开发完成后，团队解散继续下一个迭代。

不得不承认，第一种是我们期望能达到的样子，但在国内现行的组织风格下，第二种很可能是主流（个人观点，可能有偏见，谨慎！）
因此在考虑是否独立“应用中心”的概念时，我持赞成票。

[colynn]

如果我们调整为应用为中心，也就是应用的数据统一维护，也是可以支撑第一种场景的，并且组织架构与微服务很有可能不匹配（个人关点，因为微服务的管理者是开发者，而组织架构的维持者是行政部门），所以也是支持以“应用”为中心的调整

Next

既然方向一致，我们可以基于上文的待确认项（TBD）及细节（比如镜像规则、yaml配置等）麻烦考虑会回复下自己的看法， @sampsonye @fanhousanbu ,

Then

然后我们通过sig的线上会议的方式再邀请大家一起确认（具体时间会通过微信群确认）,梳理待办项

[fanhousanbu]

一般我们会遇到两种形式的研发团队 第一种，组织架构与微服务相匹配的团队。整个系统会被拆分成多个“服务”，每个服务由固定的小组来维护，所有针对这个服务的迭代都是串行的 第二种，赶工型团队。系统尚未进行服务化拆分，甚至没有拆分。大多数以项目方式进行迭代，立项后确定团队成员，确定影响的系统范围，项目开发完成后，团队解散继续下一个迭代。

不得不承认，第一种是我们期望能达到的样子，但在国内现行的组织风格下，第二种很可能是主流（个人观点，可能有偏见，谨慎！） 因此在考虑是否独立“应用中心”的概念时，我持赞成票。

巧了，@sampsonye 与我恰好同时分别应用了这两种形态，我当时所处的场景是第一种，但由于整个DevOps系统的设计是按上面说的第二种场景迭代，导致后续迭代中增加的功能（例如审批、通知、自动合并分支等），都是按第二种场景考虑设计；这就引出一个话题：AtomCI中，如果未来的设计是将“应用”与“项目”隔离，那依然有团队想采用项目与应用一一对应的方案，那是否需要考虑这种“玩法”是否在周边功能上有更精简的需求呢？

[colynn]

@fanhousanbu 『项目与应用一一对应的方案』 可以再具体阐述下，我理解将应用和项目拆分为平行资源，独立管理 也是可以支持这个的吧，

另外对于 TBD的那几点，你们有什么看法吗 @sampsonye

[sampsonye]

TBD我的想法：

1. 『应用管理』包含应用的基础信息，yaml配置、（镜像版本规则、chart版本规则等）？
   认同，可能还有“标签”相关的配置，用于轻量级分组需求
2. 应用的基础编排定义调整至『应用管理』保留，『项目』内关联应用后可以继承或是修改yaml？
   项目内默认继承yaml配置，可根据项目环境不同调整仓库地址
3. 如何解决应用-镜像-代码仓库的关联关系？
   应用有多种具体类型（某个固定资源如Endpoint、某个固定镜像的Registry地址、以及源代码仓库地址），应用构建的产物（可以称之为制品）可以是镜像或者其它（如一段生成Endpoint的脚本）

[gosszhang]

【应用管理】这个模块是应该与【项目管理】平行，还是在【项目管理】下面？
我的想法是在【项目管理】下面，遇到有些组织需要多个项目组并行，是否可以引入一个【版本迭代】的概念，基于这个进行多项目并行管理。
按我这思路的话，【项目管理】叫做【产品管理】会更合适。

[colynn]

基于 2022年01月19日的讨论，会将“应用” 拆分为与项目 平行的资源，进行独立的管理与模板维护

[colynn]

�综合考虑，我的应用纬度调整，调整为如下状态：@sampsonye @fanhousanbu 欢迎讨论

『我的应用』 ：

• 只管理应用的基础信息（代码库地址、名称、描述、语言、构建目录、Dockerfile、编译环境、helm模板）

• 应用的标签管理；

『我的项目』引入『我的应用』，后续逻辑沿用目前的1.3.0版本的方式

『系统管理』- 『服务集成』下新增代码库的集成，这里是统一为在服务集成下添加类型，还是新增一个tab单独做代码库的集成信息？ @sampsonye @fanhousanbu

为什么还要调整

1. 因为应用的全局唯一我认为很有必要，方便后期功能拓展及管理，比如新增应用的默认运行配置、dockerfile模板化、helm模板等
2. 可以理解为 应用也是一种原信息的统一维护， 『我的项目』下的引入的应用是具体场景的实际化。

[sampsonye]

『系统管理』- 『服务集成』下新增代码库的集成，这里是统一为在服务集成下添加类型，还是新增一个tab单独做代码库的集成信息？

个人意见是单独Tab承载，从场景来看代码库和基础服务(Registry、k8s等)不是一个维度的东西，前者的维护者可能是开发，后者的维护者大概率是运维

另： 本次变更考虑引入helm来进行发布吗？

[colynn]

单独Tab承载：
%colynn：类似于"我的应用“ -- 有两个子菜单（应用列表、应用代码库设置）

本次变更考虑引入helm来进行发布吗？
%colynn: 其实我们这次调整相当于重构应用，觉得至少过了这个版本才可以引入helm

[colynn]

应用纬度的调整，我整理的大致样子：https://axhub.im/pro/09f7c1cefa188a03/#g=1&p=%E6%88%91%E7%9A%84%E5%BA%94%E7%94%A8