目前项目组是采用自动部署版本的方式，即在mergeCI结束后会自动触发deployCI流水任务，完成此次代码合入后新版本自动部署操作。此外，在加上前期的verifyCI，该流水任务包括了对代码硬编码、kw、复杂度、sonar指标等方面进行监控；按理来说，这整个流水线算是一套完整的工作流程了，能够满足项目进展需求了。不过经过这次的一点小意外、小波澜后，感觉整套CI流程还是有待改进、完善的地方。
首先，说说这一次的小波澜吧。由于开发人员在不同时间段进行了多次PR操作，最早的一次PR包括前端、后端代码，后面几次的PR只包括后端代码；由于审核人员没有及时合入这些PR，而是在同一时刻对上述所有的PR进行审核；本以为最新的镜像版本会包括开发人员已提交的功能了，在实际操作过程中发现其实不然，前端新提交的功能没有在本次版本中体现出来。
接着，分析这一原因。在gerrit上查看最新的代码记录，发现代码库中是包含了所有提交的代码。那为何新版本中没有体现出新功能呢？只好分析最早一次PR（包含前端代码）时deployCI过程中制作镜像的时间与容器中前端最新版本的时间，发现容器中前端最新版本的时间要比deployCI过程制作镜像的时间早，这样就可以初步确定了前端最新版本镜像并没有包括最新提交的前端代码。那这是为何呢？就连最后一次的PR操作，也没有导致前端重新部署版本吗？只好联系CI负责人员，确认一下此事。
经过沟通，初步了解到了deployCI在制作镜像时会自动区分前端和后端，若此过程只包含后端代码，那么只制作后端的镜像；若此过程只包含前端代码，那么只制作前端的镜像；若此过程既包括前端代码，又包括后端代码，那么会同时制作前端镜像和后端镜像。据此，就可以分析到几次PR操作时所能够制作的镜像都有哪些了；第一次PR操作包括了前端代码和后端代码，所有会同时制作两个镜像；最后一次的PR操作只包括了后端代码，所以只会制作后端镜像。但是，刚才我们在上述分析时已经确定了前端最新的版本镜像时间要比第一次PR操作后的deployCI时间早，所以可以肯定的是第一次PR操作后的deployCI并没有成功制作前端镜像。那为什么会失败呢？我们进一步分析。
与CI相关人员沟通了解到，针对同一个项目服务名称在同一个流水线中若两次deployCI的时间相差很近，即前一次还没有结束，这一次又开始了，那么最后一次deployCI会中断前一次deployCI制作镜像过程。根据这个特性，就可以很好地解释了第一次PR后deployCI没有成功制作前端镜像了。因为审核人员是在同一个时刻将所有的PR审批完，导致每次mergeCI的间隔都很短，从而每次的deployCI间隔也很短，这样最终的镜像都是以最后一次deployCI操作为准了；由于最后一次PR只包括后端代码，因此最后一次的deployCI只会制作后端的镜像，前端镜像只维持第一次PR之前的版本了。
最后，我们来说说改进之处：
（1）CR人员要及时审核代码
（2）前后端的CI分离
（3）若前后端CI不分离的话，那么在deployCI中还要智能处理中断上次deployCI的镜像制作，我们假设上一次deployCI包括了前后端的镜像制作，那么这次deployCI如何中断上次的镜像制作，具体情况如下：
- 若本次deployCI只包含前端镜像制作，那么本次只能中断上次的前端镜像制作，保留上次的后端镜像制作；
- 若本次deployCI只包含后端镜像制作，那么本次只能中断上次的后端镜像制作，保留上次的前端镜像制作；
- 若本次deployCI同时包含了前端、后端镜像制作，那么本次都要中断上次的前端、后端镜像制作。