持续集成与持续交付，涉及到的人和流程是不同的，并且根据公司规模和交付应用的规模，复杂程度也是不同的。

• 基本的，开发，测试，产品，运维各个工种之间基于持续集成和交付系统之上，他们的关注点不同，如何很好的区分以及协作，这是首先要考虑的问题。
• 多个项目或者产品线并发情况下，特别是项目之间有依赖关系，人员在这些项目之间如何很好的资源分配，保证不强依赖，不冲突，那么就需要在集成交付各个环境需要很好的设计，比如git代码分支的设计，docker容器自动部署并发布各个开发分支进行测试的设计等。如果集成工作量很大时，需要根据实际情况进行分布式部署集成系统，特别的，当交付的系统成规模后，而且语言多样，并且要严格的执行发布流程，那就需要结合业务自研发布系统和构建系统。

先看一张图，集成交付的一般流程。

上图是提交代码后触发了自动构建流程，是单个开发人员的流程，如果是多开发人员，我们看看问题在哪里。

• 后端2个feature之间有依赖，否则无法联调，在合并到dev分支之前
• 前端的某个feature分支和后端的某个feature分支之间如何联调
• 前端的2个feature分支之间有依赖，如何联调

解决以上问题有两种方式，第一种通过配置文件方式，在每个开发人员提交代码工程里面加上该文件（*.yml），文件中描述了本次提交后自动构建时，需要合并依赖构建的那个工程，那个分支，那个版本，让jenkins统一进行构建并发布在先，这样解决了依赖问题；第二种方式，就是自研构建平台，手工进行选择构建即可。这两种方式可以根据实际公司情况选择。

构建完成后，打包docker镜像pushu到仓库，调用k8s集群进行拉取部署，此时就可以进行MR之前的测试联调，等通过以后提交MR，通过后自动删除k8s分配的资源即可。该过程中，开发人员只需要进行编写配置文件即可，然后在做其他工作，无须等待测试过程。

所有合并到dev分支后，进行同样的流程，单元和集成测试，自动开始k8s集群环境进行实例部署，测试通过后在继续部署到测试和预发布环境，该过程中，每个环节都可以通过相关消息通知机制通知相关分支和部署负责人，及时修复和更正。

既然有了docker和k8s这种好东西，自然能够自动化的一定要自动化，比如每次测试的镜像环境，不管是开发人员的feature分支，还是集成测试的镜像，都可以通过公共镜像方式共享环境，并且对于上线后的环境，也可以拉取回来到测试和stage环境中。

总结一些，每个公司根据自己业务情况，来合理使用这些工具，但是建议代码质量在pr之前就要进行一次强制的自查和外部审查，这个是关键。好的流程和机制才能保证高质量和高效率的交付。