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）
![CI/CD-云主机场景CD篇-[前端后端项目|发布|回滚|ActiveChoice参数]](https://www.hebbao.com/wp-content/themes/begin/img/loading.png)
评论