什么是CD
我们不妨看看CD全程Continuous Deployment
“持续部署”,就是“自动化地、持续不断地把通过测试和验证的代码部署到生产环境或其他指定环境”的过程。
想象一下,你在家里做饭。以前你可能需要手动洗菜、切菜、炒菜,每一步都要等上一步完成才能进行。但现在,你有一个智能厨房,它能够在你把食材准备好之后,自动帮你完成洗菜、切菜、炒菜这一系列流程,最后直接把一盘热腾腾的菜端到餐桌上。这个过程就像是持续部署。
CI
由于当前项目非常简单,总共就二十多个issues,所以没有配置CI,什么是ci,可以参考柯晓彬写的github action配置第一个CI 和实现钉钉推送。
整体流程
服务器也可以是 gitlabCD(本质上也是gitlabCI) 我们团队当前采用的当前这中放是,并没有采用服务器。
上面是ci和cd的整体流程
CI
* 在本地的当前具有新功能的分支上传到代码到gitlab
* 把新功能分支请求到maim分支(此时触发pipeline,执行gitlabCI)
* gitlab执行自动化测试
* gitlabCI回传将结果至gitlab,gitlabCI执行成功则可以合并到当前分支
CD
* 当前具有新功能的分支合并到主分支(main)后,就可以构建项目了,过程(repository->tags-new tag)
* 此时触发pipeline,执行gitlabCI
* 当gitlabCI 自动化测试执行成功后
* 自动部署到服务器
* gitlabCI 回传结果到gitlab
项目部署
前面对整体流程有了一定了解,现在就需要写脚本完成自动部署了
理解几个比较重要的关键词
* workflow: 整体指定的过程
* variables:定义变量
* stages:设置运行步骤
* tags:设置运行环境
* script:设置要执行的命令
* rules: 设置条件
* dependencies:设置依赖
demo
结合简单demo理解这些变量的作用
# 当请求合并的时候或者tag的时候才出触发整个工作流
workflow:
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event" || $CI_COMMIT_TAG != null'
variables:
# 工程名称唯一
PROJECT_NAME: "DEMO"
stages:
- build
- deploy-cd
angular-build:
tags:
- docker
stage: build
# 从该镜像生成的容器中运行作业
image: registry.cn-beijing.aliyuncs.com/mengyun/node-chrome:18.16.0
script:
- cd web
- npm run build
rules:
- if: $CI_COMMIT_TAG != null
spring-build:
tags:
- docker
stage: build
image: JDK/jdk17-mvn-git
script:
- mvn -v
- mvn package -Dmaven.test.skip=true
- mv target/*.jar ../api.jar
rules:
- if: $CI_COMMIT_TAG != null
deploy:
tags:
- debian-cd-tute
stage: deploy-cd
dependencies:
- spring-build
- angular-build
script:
- ls -a -ls
- mkdir -p /home/app/${PROJECT_NAME}
rules:
- if: $CI_COMMIT_TAG != null
该配置对应下面的pipeline
从上图看出运行步骤是依次执行的,只有当angular-build和spring-build 成功后,才会执行deploy-cd,因为前面设置了依赖。
假期计划
之前的计划得重新规划下,以前比较喜欢借助翻译工具,进行翻译, 但是翻译出来的总有不对的。
为了提高自己的英语水平,现在给自己两天安排一篇官方文档
例如:
Introduction to Transactions in Java and Spring
遇到不会的高频词记录下来,每天花点时间背背
参考资料
https://segmentfault.com/a/1190000041273079
https://docs.gitlab.cn/jh/ci/quick_start/
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。