对DevOps流水线设计的优化和改进实践( 二 ) 对于DevOps过程支撑平台

打包操作：实际上即基于构建完成的部署包来生成镜像。该操作一般首先基于一个基础镜像文件基础上进行，在基础镜像文件上拷贝和写入具体的部署包文件，同时在启动相应的初始化脚本。
那么首先要考虑构建操作和打包操作如何松耦合开。
打包操作简单来就是就是一个镜像制作，需要的是构建操作产生的输出。我们可以对其输出和需要拷贝的内容在构建的时候进行约定。而打包任务则是一个标准化的镜像制作任务，我们需要考虑的仅仅是基于1）基于哪个基础镜像 2）中间件容器默认目录设置 3）初始化启动命令。
即在实际的打包任务设计的时候，我们不会指定具体的部署包和部署文件，这个完全由编排的时候由上游输入。
注：在前期流水线设计的时候，为了考虑灵活性，我们往往会对打包过程的脚本自定义完全放开，包括基于哪个dockerfile制作镜像，镜像制作过程中需要运行哪些指定的脚本文件，进行哪些文件拷贝操作等。但是为了考虑灵活性，这些都必须提前进行约定，即打包操作中都统一调用一个标准命名的初始化脚本文件。
部署操作：部署操作相当更加简单，重点就是将镜像部署到哪个资源池，哪个集群节点，初始化的节点配置等。具体部署哪个镜像不要指定，而是由上游任务节点输入。
经过上面的思考，我们希望达到一个目的就是我们会形成标准的任务操作节点，完全适用于多个不同的微服务和应用项目。而不再需要针对每个项目都去建立不同的任务操作节点。
比如对于部署操作，我们如果有两种资源调度策略，那么我们创建两个部署操作任务模板即可。对于打包操作，我们根据不同的开发语言，构建不同的打包操作模板即可。
任务节点间松耦合设计的意义
这种松耦合设计才能够使流水线编排更加灵活。
比如我们在进行了构建打包后，我们希望同时将打包内容部署到开发环境和测试环境。那么则是打包动作完成后需要对接两个应用部署任务。这两个部署任务都依托上面的打包结果进行自动化部署，可以并行进行。
对于测试环境部署完成后，我们需要进行测试人员手工验证测试，如果测试通过，我们打标签后希望能够直接发布到UAT环境。而这种操作我们也希望在一个流水线来设计和完成。这样我们更加容易在持续集成看板上看到整个版本构建和迁移的完整过程。
如果这是在一个大流水线里面，那么对于UAT环境部署更多只是一个镜像的迁移操作，因此就需要一直去追溯流水线上的最近的一个打包任务节点，同时取该任务节点产生的输出来进行相应的环境部署操作。
在谈DevOps的时候，一个重点就是和QA和QC的协同，因此在流水线编排的时候一定要考虑各类测试节点，包括静态代码检查，自动化的单元测试，人工的测试验证。同时最好基于持续集成实践，能够将测试过程和整个自动化构建过程紧密结合起来。
简单来说，测试人员发现build1.0.0001版本4个bug并提交，那么在下次自动化构建完成并单元测试通过后，测试人员能够很清楚的看到哪些Bug已经修改并可以在新构建的版本进行验证。只有这样才能够形成闭环，整个流水线作业才能够更好的发挥协同作用。
两级流水线设计在进行微服务架构设计和开发的时候可以看到，原来的单体应用已经拆分为多个微服务。比如一个财务报账应用，我们拆分为报销管理，系统管理，流程引擎，数据管理，接口管理，门户管理六个微服务模块。
那么整个报账应用实际上就是产品-》微服务的两级架构模式。
在整个DevOps支撑平台基础数据配置的时候，我们首先需要支持将报账应用配置为独立的产品，并在该产品下配置6个独立的微服务项目。
我们最终向客户交付的是整个报账应用产品，但是对于开发和持续集成的过程则是按照微服务项目的粒度进行管理。特别是在后续运维变更的时候，如果仅仅是报销管理模块发生了变更，我们希望的仅仅是对报销模块流水线进行运行和持续集成，而不是所有的微服务模块都进行重新构建。
文章插图
基于两级流水线设计，我们希望达到的效果就是：
我们不用去关心产品变更的时候究竟变更了哪些微服务模块，即一次变更我们直接启动产品流水线。产品流水线启动后自动检查哪些微服务发生变更，如果发生变更则出现持续集成操作，如果没有变更直接调整到End完成节点。