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

文章插图
对于DevOps过程支撑平台，我在前面已经写过相应的文章。在整个DevOps平台的建设过程中可以看到持续集成和持续交付始终都是平台的一个重要内容。而在整个持续集成和交付过程中，流水线设计又是相对关键的一个内容。
通过流水线设计可以很灵活的通过可视化配置的方式，将我们软件持续集成中涉及到的编译构建，打包，部署，代码检查，测试，环境迁移等各种活动编排在一起，形成一个自动化执行的完成流程。通过流水线的运行，即可以实现整个软件开发，集成和交付过程的完整自动化。
DevOps流水线概述
文章插图
流水线，简单来说就是一系列组装在一起的可以执行的活动或作业。
Pipeline 流水线是指软件从版本控制库到用户手中这一过程的自动化实现是持续交付与 DevOps 的核心工程实践；Pipeline 流水线的自动化和持续流动，才能保证在不同阶段、不同节点上产品发布的一致性和稳定性，同时，也才能消除由于人工操作所引入的人为风险，同时提高效率，消除“等待”与“浪费” 。
对于DevOps流水线，主要是由各类任务串联起来，而对于任务本身又分为两种类型，一种是自动化任务，一种是人工执行任务。具体如下：

自动化任务：包括了代码静态检查，构建，打包，部署，单元测试，环境迁移等。
人工任务：人工任务主要包括了检查审核，打标签基线，组件包制作等类似工作。

而通常我们看到的流水线基本都由上述两类任务组合编排而成，一个流水线可以是完全自动化执行，也可以中间加入了人工干预节点，在人工干预处理后再继续朝下执行。
比如流水线中到了测试部署完成后，可以到测试环境人工验证环节，只有人工验证通过再流转到迁移发布到生产环境动作任务。
DevOps流水线实际上和我们原来经常谈到的持续集成最佳实践是相当类似的，较大的一个差异点就在于引入了容器化技术来实现自动化部署和应用托管。至于在DevOps实践中，是否必须马上将项目切换到微服务架构框架模式，反而不是必须。
在整个DevOps流水线中，我们实际上强调个一个关键点在于一套Docker镜像文件+多套环境配置+多套构建版本标签做法。以确保我们最终构建和测试通过的版本就是我们部署到生产环境的版本。构建操作只有一次，而后面到测试环境，到UAT环境，到生产环境，都属于是镜像的环境迁移和部署。而不涉及到需要再次重新打包的问题。这个是持续集成，也是DevOps的基本要求。
在DevOps和容器云平台集成的时候可以看到，整个流水线里面有两个分离动作。
构建和打包
【对DevOps流水线设计的优化和改进实践】在这里做下解释即编译构建是我们通过类似Maven等工具进行自动化构建形成类似JAR包等部署包的过程。而打包则是将部署包基于预先定义的镜像模板制作为镜像的过程。而在传统的持续集成操作里面，往往则没有单独的打包这个动作。
DevOps流水线节点的松耦合设计

文章插图
在进行流水线设计和开发的时候，我们的整个过程如下：

建立编译构建，打包，部署，测试等各个独立的任务节点并进行配置。
新建立一个流水线，然后将上面的各个任务节点串联在一起

但是这种模式构建的流水线你会发现，前面创建的任务节点由于定制了特殊的配置信息，导致只能够应用到你新建的特定流水线上面。或者简单的说，你要灵活进行任务节点之间的连线往往并不可能达到。
因此我们还是重新回顾下我们建立的各个任务操作节点。

文章插图
构建操作：构建我们通常采用Maven进行自动化构建，构建完成输出一个或多个Jar包或War包。
注：对于编译构建操作，我们看到重点就是指定具体的git库和分支路径，然后采用默认标准的maven构建方式进行编译构建。那么在这种方式下，我们完全可以将类似Git库配置信息配置到具体的项目基本属性里面，这样编译构建操作同样可以通用。
注意常规方式下构建完执行进行部署操作，部署操作一般就是将构建的结果拷贝到我们的测试环境服务器，同时对初始化脚本进行启动等。而在DevOps下，该操作会变成两个操作，即一个打包，一个部署。打包是将构建完成的内容制作为镜像，部署是将镜像部署到具体的资源池和指定集群。