虽然第一版的devops平台对标准化项目的部署缩减了部分时间，但还是容易存在以下问题
问题
- 服务管理混乱，组织架构拆分不明显，需求边界不明显，同时每个组都可以更改不属于组的服务，虽然有做微服务拆分，但实质上仍然按单体应用的模式去开发，导致项目的质量腐化严重，交付的质量不高
- 迭代管理混乱，各组产品人员缺乏沟通，只注重需求的叠加，同时因无法及时了解其他组迭代的功能及排期，容易导致需求重复开发，对开发和测试的工作排期也只能拍脑袋决定
- 分支管理混乱，虽然有分dev，test，uat和prod，但是由于各组开发拉取的分支随意，容易产生名称不规范，无法追溯该分支是关联哪个迭代，同时缺乏管理，导致大部分开发人员不按规范将代码合并到dev进行联调测试，而是发布到test环境，容易影响其他组的正常测试进度；发布到线上后，缺失归档，导致master分支形同虚设；发布完成的分支，缺失管理，git上的分支无法判断其是否已经发布，导致无法删除
- 配置管理混乱，虽然有做配置替换，但是整理过程中，发现大部分配置不规范，存在各个服务同一个配置，存在不同的key，导致替换的过程中，容易遗漏
- 代码版本管理混乱，各服务直接互相引用，但是版本从头到尾都是0.0.1-snapshot，容易导致被引用的服务被修改后，某些功能还想引用之前的版本，却不得不一起升级，同时也存在某些链路没有被测试到的风险
- 制品版本管理混乱，后端项目每次在测试环境构建的tag都是latest，导致构建存在问题后，无法及时回滚
devops2.0
解决问题一
每个服务通过devops录入，并设置对应的服务负责人，将该负责人对应的git权限设置为maintainer，这样避免其他人修改非该组的服务
解决问题二
通过devops维护迭代清单，每次开启一个迭代，都在devops上创建迭代清单，并录入相关的开发，测试，运维和产品人员，并录入对应的预发布时间，要修改的服务，并设置当前创建人为迭代负责人，这样每次迭代的管理都可以有效的追溯
解决问题三
定制统一的分支管理规范，并且由devops在创建迭代的时候，创建迭代分支和开发分支，并且为各开发人员分配git的develop权限，在提测并审核通过后，创建新的release分支，将各自要测试的迭代的分支，合并到release分支进行统一测试（因为公司只有一套测试环境），上线验收通过后，统一进行归档；
解决问题四
抽取统一的配置信息，将中间件连接，cdn域名，云存储桶配制等信息，其他业务相关的配置信息，由数据字典服务单独统一管理
解决问题五
代码版本管理（即pom的版本管理），由架构师提供规范进行约束，开发者自行更新版本，不由devops管理，避免升级版本过程中，提供服务的开发者无法感知，从而影响消费方的调用，同时，每次提供者的服务都需要发对应client的release版，而消费方在提测的过程中，需要更新自己引用的client为release版（snapshot版可以覆盖，会导致消费方引用不稳定的版本导致bug）
解决问题六
制皮版本管理，每次开发环境和测试环境CICD，都会由devops生成一个临时的tag，将该tag打到对应的后端镜像tag和前端静态zip包的文件名上，前后端制品都存放在私仓的snapshot目录下，测试通过后，获取对应的服务，拉取对应的服务的最新的tag，就可以找到已测试过的最新制品，发布到预发环境和正式环境，验收通过后，进行归档，会生成新的version，将该版本号与最新的临时tag进行关联，并且用该verison对master分支打tag，同时将前后端制品的临时tag修改为version，并移动到私仓的release目录下
经过上面的管理，基本可以保证最终制品的质量，同时，可以根据版本进行问题的回溯，为后续的交付提供了保证
