背景
- 云原生的背景下，应用或是运行在云主机上、或是运行在k8s中，对于我们的现状而言，云主机的应用使用jenkins来进行部署、k8s中的应用使用自建的运维平台来部署，这对于开发的使用习惯来说不够友好，多个应用同时发布需要各个平台切换
- 为了控制代码的发布频率，以减少故障率，我们对发布时间及发布频率做了控制：每天0点-12点可以发布，其余时间不允许发布。其余时间遇到紧急修复BUG类的，必要发布更新，走特殊审批流程发布
- 站在DevOps的角度来看，我们的产品需求与CICD环节是断层的。需求管理使用的是禅道，如何打通需求与发布的关联关系？
- 对于运维侧来说，应用发布权限分配未实现自动化，每次开通权限需要手工操作，如何避免或优化这一环节？
需求目标
针对以上问题，我们要做到：统一发布平台、打通DevOps工作流、优化使用体验，因为本质上，开发的诉求无非是代码最快速度触达用户。
工作流和流程图梳理
工作流
逻辑流程图
涉及到的一些细节问题
分支的开发策略？
我们采用的是分支开发主干发布，分支由系统自动创建
- 多人开发：开发直接pull该分支，并切出本地开发分支进行开发，后合并到此分支即可
- 单人开发：直接基于发布系统创建好的分支，本地开发，直接merge到主干分支
发布权限如何管控？
在打通了需求和发布的工作流后，注意，我们关注的维度已经不是某一个应用，某一个人是否拥有发布权限了，而是针对此次需求，哪些人可以有发布权限？那么有发布权限的人可以对此次需求中的所有应用，进行发布。这里我们采用的是，一个需求对应一个发布单，有了需求就可以创建发布单，发布单任何人都可以创建，但是一个需求被一个发布单关联，否则禁止创建发布单，发布单其中一项就是关联人员的选项，指除创建人外，可拥有发布权限的人员列表。
应用信息如何管理？
应用的元数据信息，统一维护在CMDB中。主要维护信息包括：应用名称、仓库地址、维护人、语言技术栈、部署类型等
关于流水线管理？
现有发布主要分为jenkins和k8s发布，可以统一放在pipeline的stage中，则发布系统可支持对jenkins流水线编排的能力。优点是归一化管理，每个应用的逻辑以jenkinsFile体现，发布逻辑透出，非常利于后续运维管理
这里假设某一个pipeline伪代码如下：
{
stage(代码检出),
stage(编译构建),
stage(部署推送),
stage(结果通知),
}
场景假设（现在需要给某一流水线统一增加代码检测逻辑）：
{
stage(代码检出),
stage(代码检测),
stage(编译构建),
stage(部署推送),
stage(结果通知),
}
综上，利用jenkins流水线可实现功能的可插拔 jenkinsFile目前有公共库的引用和每个Job运行时的数据，目前都存放在git仓库上，发布系统管理页面可支持可视化编辑，存储依然依赖GitOps的方式即可
发布平台使用过程
- 创建发布单
- 进入发布页
- 开始发布
- 等待构建
- 发布完成
