一、DevOps的理解
DevOps的概念理解
DevOps 的概念在软件开发行业中逐渐流行起来。越来越多的团队希望实现产品的敏捷开发，DevOps 使一切成为可能。有了 DevOps ，团队可以定期发布代码、自动化部署、并将持续集成 / 持续交付作为发布过程的一部分。
一句话概括就是提高生产力,快速交付！
后端开发框架：基于C#的.netCore和Java的SpringCloud,少部分项目采用python和go开发
前端开发框架：vue、react
服务部署：前端站点基于ECS的nginx部署 ，后端服务统一部署在kubernetes上
代码仓库：gitlab
项目环境：目前有6套，开发、测试、压测、集成、PRE和生产
2.2 后端服务的CICD现状
福禄后端CICD流程
CICD 流程说明
每一次的代码push，根据创建的分支，根据在gitlab的CICD文件gitlab.yml定义构建步骤，触发runner，从单元测试、通过dockerfile进行编译和生成镜像版本、将新镜像部署到K8S生成pod，然后触发接口自动化测试任务的执行
!!#00ffff 好像缺了点什么 !!
初次部署应用到kubernetes怎么做的？
服务的configmap在哪里维护的？
每个服务的gitlab.yml文件都不一样，如何维护的？
应用的域名解析怎么做？
目前有6套环境进行管理，其中开发、测试、集成、压测都是测试人员维护，预发布和生产运维人员维护；这也就要求每一个测试人员都必须对整个cicd流程和配置绝对掌握；所以当新人入职，需要掌握整个流程才能进入项目测试中，这是一个学习成本；
预发布和生产的kubernetes只有运维能够操作，当有新的服务需要上线上述环境，或者configmap有变动，或者有时候排查问题需要查看容器日志，我们只能通过运维的工单系统描述作业操作，中间文字描述可能存在理解差异，沟通成本和时间成本很大；
有的新应用我们去设置cicd的相关文件，比如dockerfile，我们发现应用的代码目录结构各种各样，这样往往就没法套用一个模板快速配置完成
2.3 前端站点的CICD现状
前端CICD流程说明
开发人员push代码到gitlab，测试人员通过jenkins拉取最新的代码到jenkins本地，然后通过jenkins与服务器之间的传输管道，将要部署的文件更新到目标服务器，并触发UI自动化的job
完整的过程来看，也缺点内容
一个新的站点部署，nginx需要做一些配置初始化工作，比如域名、路径的配置
前端的配置文件是如何管理的
跟后端应用一样，前端的PRE和生产环境也是运维处理，所以当一个新的应用上线我们也需要发工单，描述具体操作，然后运维执行工单；配置文件一般不会变更，所以我们在jenkins推送更新文件到目标服务器的时候，将配置文件做了过滤处理。后续需要变更通过工单执行
2.3 痛点你看到了吗 2.3.1 安全管控缺位代码安全：CICD的起点在gitlab里面，所以大家都有gitlab的账号，代码安全管控缺位
线上安全：线上项目部署也是通过gitlab的cicd直接触发，审批流程缺失
2.3.2 管理成本维护账号多：gitlab账号、jenkins账号、kubernetes账号（本地和阿里云），每一个人员都需要上述账号，运维管理麻烦，大家每个平台维护自己的账号也麻烦
工单沟通：工单编写、沟通过程花费时间较多
代码规范：项目组多，微服务也多，代码框架各自发挥，无论是流程维护还是问题排查都增加了难度
三、研发管理平台（RDMS）应运而生 3.1 如何理解这个平台!!#ff0000 工具链到平台的转变 !!
当前的cicd是对工具链进行了打通，但需要大家登录各个工具平台操作，我们希望对工具集进行功能整合，打造一个系统平台，并且将CICD的技术细节进行屏蔽，开发人员能够专心进行业务需求的开发，测试人员能够专注到需求测试任务中，而运维人员能够解放繁重的工单内容，投入到服务高可用的建设上！
3.2 业务功能设计
福禄研发管理平台功能结构图 3.2.1 功能说明