CI/CD-云主机场景的持续部署实践
0. 准备工作项目标准化
公司里面要使用流水线要做持续集成CI/CD的项目越来越多,这对流水线的设计和开发有不同的要求。我们经常听到用户的反馈:
- 各种不同语言的技术栈, 如何使流水线适配呢? 从不同技术栈维护一套流水线模版,到我们使用共享库进行统一的管理和维护。
- 对于不同的项目,大家管理代码的方式也不同。可能还有一部分用户在使用Svn等不同的版本控制系统。
- 不同的项目,开发模式也不太一样, 编译构建工具不同,发布的方式也有不同的地方...
等等,不止上面的问题。所以在做流水线的使用应该提前把项目团队的规范定义好, 这样后期项目改造后可以直接集成CI/CD流水线。更加便捷。
跟进项目团队信息
信息项 | 描述 |
业务简称/编号 | hwf-app |
开发模式 | 特性分支开发,版本分支发布,主干分支作为最新代码 |
项目类型与构建方式 | 前端: vue项目, npm打包, 制品目录 dist |
后端:springboot项目, maven打包, 制品目录 target | |
发布主机环境(vm) | LB: 192.168.1.10 |
Server: 192.168.1.11~192.168.1.13 |
制定项目CI/CD规范
通过上面的信息,我们采用如下规范:
工具链 | |
GitLab 代码库 | 仓库组: hwf-app |
项目仓库后端: hwf-app-service 前端 hwf-app-ui | |
Jenkins作业 | 文件夹: hwf-app |
作业命名: 后端 hwf-app-service 前端 hwf-app-ui | |
CI构建规范 | 前端项目采用npm打包后统一放到dist目录下, 静态文件以tgz打包。 |
后端项目采用maven打包后统一放到target目录下,以jar包。 | |
Sonar代码报告 | 前端项目:hwf-app-ui 后端项目: hwf-app-service |
项目团队可以使用hwf-app命名的自定义质量规则和质量阈。 | |
Nexus制品库目录 hwf-app | hwf-app-service/version/hwf-app-service-version.jar |
hwf-app-ui/version/hwf-app-ui-version.jar | |
版本: 分割release分支获取版本号 | |
发布规范 | 用户输入版本,下载制品库,使用脚本启动服务。 |
gitlab仓库
Jenkins作业
CI/CD流水线设计
总体目标:
我们将CI和CD分成两条流水线作业。
- CI作业: 用户输入版本分支后下载代码,进行构建扫描最终将制品上传到制品仓库。
- CD作业: 用户输入发布版本和选择要发布的主机IP后,下载制品,将制品和服务启动脚本cp到目标机器的发布目录, 远程执行启动脚本启动服务并进行健康检查。
jenkinsfile
第一行就是要导入我的共享库。@Library("hwf-app@main")_
我们在共享库中编写了一些特定的处理类:
- src/hwf/devops/Checkout.groovy 代码下载
- src/hwf/devops/Build.groovy 代码构建
- src/hwf/devops/Nexuspackage.groovy 制品管理工具
- src/hwf/devops/Sonar.groovy SonarQube扫描
- src/hwf/devops/UnitTest.groovy 单元测试
在Jenkinsfile中导入这些类
import hwf.devops.* // 导入库 def checkout = new Checkout() def build = new Build() def unittest = new UnitTest() def sonar = new Sonar() def nexuspackage = new Nexuspackage()
有些参数需要用户在Jenkins页面构建前填写的:
- 用户需要在jenkins作业中配置好要构建的代码仓库的地址。(一般不需要改, 可以使用选项参数)
- 每次构建需要输入此代码库要构建的代码分支。 (字符串参数)
- 选择本次构建要使用的构建工具(选项参数maven、ant、gradle、npm)

评论