GitLab CI + Jenkins 双流水线模式Jenkins 端实现

最终完整实现流程

plaintext

1. GitLab CI 构建镜像 → 推送到镜像仓库
2. GitLab CI 调用 Jenkins API → 告诉Jenkins：镜像好了
3. Jenkins 收到通知 → 等待人工选择发布环境
4. 人工点击【发布】→ Jenkins 执行部署脚本
5. Jenkins 调用 K8s 部署到对应环境（dev/test/pre/prod）
6. 等待服务启动成功
7. Jenkins 自动触发对应环境接口自动化测试
8. 测试成功 → 发布完成；失败 → 标红、阻断

---

1. 镜像构建完成 → 通知 Jenkins

实现方式：GitLab CI 里调用 Jenkins API

就是在 .gitlab-ci.yml 最后加一行：

bash

运行

curl -X POST \
  "https://jenkins.xxx.com/job/Deploy/buildWithParameters?token=xxx&imageTag=$VERSION"

这句话的意思： "Jenkins，我镜像打好了，版本号是 x.x.x，你可以准备部署了"

Jenkins 收到这个请求，就会触发一个任务。

---

2. Jenkins 收到通知 → 人工选择发布环境

实现方式：Jenkins 参数化构建 + 等待人工输入

Jenkins 里配置：

① 开启 "参数化构建"

添加一个下拉选项：

plaintext

ENVIRONMENT
├── dev
├── test
├── pre
├── prod

② 配置 "等待人工确认"

Jenkins 收到 GitLab 通知后，不自动执行，停在这里等点发布。

在 Jenkins 页面看到：

plaintext

请选择发布环境：[ dev / test / pre / prod ]
【确认发布】按钮

即： "需要在 Jenkins 确认发布环境"

---

3. 人工点击【发布】→ Jenkins 调用 K8s 部署

实现方式：Jenkins 执行 shell 脚本 → kubectl 操作 K8s

Jenkins 里的部署脚本：

bash

运行

# 选择的环境变量
ENV=$ENVIRONMENT

# 把镜像更新到 K8s 对应环境
kubectl set image deployment/my-app my-app=镜像地址:$VERSION -n $ENV

这句话意思： "K8s，把 $ENV 环境里的 my-app 服务更新到新版本"

K8s 收到命令 → 自动拉取镜像 → 重启服务。

---

4. 部署完成 → Jenkins 自动触发对应环境接口自动化

实现方式：Jenkins 部署成功后，自动跑测试脚本

Jenkins 继续执行下一步：

bash

运行

# 根据环境，自动跑对应接口测试
if [ $ENV = "dev" ]; then
  pytest test_api.py --env=dev
elif [ $ENV = "test" ]; then
  pytest test_api.py --env=test
elif [ $ENV = "pre" ]; then
  pytest test_api.py --env=pre
elif [ $ENV = "prod" ]; then
  pytest test_api.py --env=prod
fi

选了什么环境，Jenkins 就自动跑对应环境的接口自动化。

不需要人工干预，完全自动。

---

5. 接口测试结果 → Jenkins 展示成功 / 失败（阻断发布）

如果接口测试失败：

plaintext

exit 1

Jenkins 会直接标红，发布流程中断，不会继续。

---

总结：最核心的 4 个技术点

1. GitLab CI → Jenkins ：用 curl 调用 API
2. Jenkins 选择环境：参数化构建（下拉框）
3. Jenkins 部署 ：执行 kubectl 命令操作 K8s
4. 触发接口自动化：部署成功后自动跑测试脚本

GitLab CI 负责构建镜像并通知 Jenkins； Jenkins 提供人工选择环境的入口，确认后调用 K8s 部署； 部署完成后，Jenkins 根据选择的环境自动触发对应环境的接口自动化测试，完成发布校验。