企业官网建设流程全解析

CI/CD 这套东西，最容易被忽略也最值得认真搭的，就是测试流水线。我经常被同事问：你们项目每次提交代码后，单测、接口测试、镜像构建、部署测试环境，是怎么串起来自动跑的？其实就是 Jenkins + GitLab 这套组合，GitLab 管代码和触发源，Jenkins 管任务编排，中间用 Webhook 和凭证打通。这篇就从一个真实 Python 项目出发，把这条测试流水线的完整搭建过程拆开讲，从环境部署、连接配置、Pipeline 脚本，到 Docker 镜像构建和自动部署，最后再对比一下 GitLab CI 的写法，顺便把高频报错和权限安全一起说清楚。适合正在搭 CI/CD、或者想把手动测试流程自动化的人参考，小白照着做也能跑通第一版。

1. 整体设计思路与工具选型

1.1 为什么选 Jenkins + GitLab 这套组合

先聊工具选型。市面上的 CI/CD 工具很多，GitLab CI、Jenkins、GitHub Actions、Drone 都是常见选择，但国内团队用 GitLab 做代码托管的比例非常高，而 Jenkins 又是老牌自动化引擎，插件生态极其庞大，这两者结合是很多公司默认的基础设施组合。

GitLab 的核心职责是代码的起点：管理分支、处理 Merge Request、做代码评审、维护 SSH 密钥和 API Token，这个层面它做得非常成熟。Jenkins 的核心职责是从 GitLab 拉代码之后的一系列自动化动作：跑测试、做静态检查、构建镜像、推送到仓库、触发部署。分工很清晰——GitLab 管入口，Jenkins 管流程。

有人会问，GitLab 不是自带了 CI/CD 吗，为什么还要单独上 Jenkins？这个问题没有绝对答案。GitLab CI 胜在集成度高、不需要额外维护一套 Jenkins 服务，配置全部写在一个.gitlab-ci.yml文件里，非常适合流程相对固定的小团队。但 Jenkins 的优势在于插件生态和任务编排能力，尤其是当你需要同时管理多个项目、调用各种外部系统、做复杂的构建矩阵，或者团队已经沉淀了很多 Jenkins 共享库时，Jenkins 会更顺手。

我实际遇到的很多场景是：代码在 GitLab，测试要连内部测试环境、要跑安全扫描、要往 Harbor 推镜像、要通知企业微信或邮件，这些环节 Jenkins 都有现成插件，配置起来更快。所以如果你在纠结选型，我的建议是先看团队规模和流程复杂程度，别盲目跟风。流程简单就 GitLab CI 起步，等真需要 Jenkins 的时候再迁也不迟。

1.2 一条完整测试流水线的链路设计

设计流水线之前，先在脑子里画一遍代码从提交到上线测试环境的全链路，这条链路就是 CI/CD 的核心骨架：

开发提交代码到 GitLab 分支；GitLab 通过 Webhook 通知 Jenkins 有新提交；Jenkins 触发 Pipeline，按阶段依次执行：拉取代码（Checkout）、准备依赖环境、跑单元测试、跑静态分析、跑集成测试、构建 Docker 镜像、推送到镜像仓库、部署到测试环境。

每一个环节都有明确的目的。单元测试要保证逻辑正确性，静态分析要保证代码风格和基本安全性，集成测试要验证模块之间能不能协同工作，构建镜像和部署则是把可交付的产物落到测试环境。任何一个环节失败，整个流程就停下来，就像交通灯亮了红灯，不允许带着问题的代码继续往下走。

这里要特别说一个理念：质量关卡要前置。很多团队习惯先写代码、最后再补测试，结果流水线形同虚设。真正有效的流水线，应该在每次合并到主干之前就把测试跑完，而不是等集成了再回头补。所以我在设计 Pipeline 时，会把质量要求作为一个独立的检查点，测试没过就不允许进入构建和部署阶段。这样虽然第一次搭的时候麻烦一点，但后面解放的是整个团队的生产力。

1.3 选型时常见的纠结

除了 Jenkins 和 GitLab CI 的取舍，还经常有人纠结是否要上 Kubernetes。这里我给个个人建议：如果只是内部测试环境，Docker Compose 足够用了，上 K8s 的维护成本很高。什么情况下考虑 K8s？多环境隔离要求高、需要弹性扩缩容、或团队本身已有 K8s 运维能力。否则为了一个测试流水线引入一套 K8s 集群，是给自己找活干。

另外数据库、缓存这些依赖，我建议用 Docker 容器跑在测试环境里，不要和开发机混用。原因很简单：流水线要可重复，环境必须干净、有版本、可重建。你不想遇到"代码一样，但本地测试过了、服务器上挂了"这种经典问题吧。

2. 前置作业：Jenkins 部署与 GitLab 连接配置

2.1 Docker 方式快速部署 Jenkins

Jenkins 的安装方式有几种：直接下载 WAR 包、用系统安装包、或者用 Docker 跑。我最推荐 Docker 方式，干净、可迁移、升级方便。

在 Linux 服务器上，一条命令就能启动：

docker run -d \ --name jenkins \ -p 8080:8080 \ -p 50000:50000 \ -v /opt/jenkins_home:/var/jenkins_home \ -v /var/run/docker.sock:/var/run/docker.sock \ -e TZ=Asia/Shanghai \ jenkins/jenkins:lts

注意我做了两个挂载：第一个把 Jenkins 的配置目录挂到宿主机，这样容器销毁重建后配置不丢；第二个挂载/var/run/docker.sock，让 Jenkins 容器内可以直接执行 docker 命令，这是后面构建和部署镜像的关键。

第一次启动后，用docker logs jenkins找到初始密码，然后访问http://服务器IP:8080解锁。解锁后会让你装插件，我建议选择"安装推荐的插件"，后续再按需补充 Git、Pipeline、Docker Pipeline、Blue Ocean、Email Extension 这些。

在 Windows 上跑 Jenkins 容器也类似，注意挂载路径要用 Windows 的目录格式，且 Docker Desktop 需要在设置里把共享磁盘打开。如果你只是想本地快速体验，不挂载宿主机路径其实也能跑，只是重启后配置会丢，所以我宁可多一步，也一定要把持久化做上。

2.2 GitLab 侧的准备：SSH 密钥与 API Token

GitLab 这边要做的准备工作有两块：SSH 密钥和 API Token。

SSH 密钥用于 Jenkins 拉取代码。在 GitLab 上打开用户设置里的 SSH Keys 页，然后把 Jenkins 服务器上生成的公钥粘进去即可。生成命令很简单：

ssh-keygen -t ed25519 -C "jenkins@yourcompany" -f ~/.ssh/id_ed25519

私钥放在 Jenkins 服务器的~/.ssh/目录，公钥内容加到 GitLab 用户配置里。这里要注意一个细节：不要给 Jenkins 用某个员工的个人账号，最好单独建一个机器人账号，既方便权限管理，也能避免员工离职后流水线跟着失效。

API Token 则是给 Jenkins 调 GitLab API 用的，比如创建 Webhook、更新 Commit 状态、拉取项目信息都需要它。在 GitLab 用户设置的 Access Tokens 里生成，记住勾选 api、read_repository 这两个范围，生成后立刻复制保存，因为只会显示一次。

关于注册的问题，顺便多说一句：如果用的是 GitLab 官方 SaaS 版，注册时要求信用卡验证，这是官方为了防滥用，和个人没关系。自己部署的社区版完全没有这个限制，安装完就是自己的，想建多少用户都行。

2.3 打通 Jenkins 与 GitLab：凭证与连接配置

环境就绪后，要做的第一件事是安装 GitLab 插件，然后在 Jenkins 系统配置里添加一个 GitLab Connection。

打开 Jenkins 的系统管理 -> 系统配置，找到 GitLab 区域，填入 GitLab 的 URL（比如http://gitlab.example.com），然后添加一个类型为 GitLab API Token 的凭证，把刚才在 GitLab 生成的 Token 粘进去。点Test Connection，如果返回 Success，说明 Jenkins 和 GitLab 已经打通。

很多新手在这一步报错：login failed. check api token or gitlab version，这个报错十有八九是凭证类型选错了，填成了 Username with password 而不是 GitLab API Token；或者 Token 权限勾选不够，只勾了 read_user 是不行的。还有一种情况：GitLab 是旧版本，API 路径和插件期望的不一致，这种就升级 GitLab 或者换用对应版本的插件。

接下来创建流水线任务。在 Jenkins 新建一个 Pipeline 任务，源码管理选 Git，填 GitLab 仓库地址（建议用 SSH 形式，比如git@gitlab.example.com:group/project.git），Credentials 里选择之前配置的 SSH 私钥。这样 Jenkins 就能凭私钥从 GitLab 把代码拉下来了。

Webhook 的配置在 GitLab 侧。进入项目设置 -> Webhooks，URL 填 Jenkins 的/project/任务名地址，比如http://jenkins.example.com:8080/project/order-api，触发事件勾选 Push events 和 Merge Request events。保存后点 Test，确认能收到 200 响应，流水线就会在每次代码提交后自动触发。

2.4 Jenkins 常用环境变量与基础设置

如果在 Pipeline 脚本里要写死在服务器路径上，总有一天你会后悔。Jenkins 提供了一批内置环境变量，写脚本时要学会用它们：

还有一个容易忽视的设置是时区。Jenkins 容器默认用 UTC，日志和邮件通知的时间会差 8 小时，非常误导排查。解决方式就是在启动容器时加环境变量-e TZ=Asia/Shanghai，一劳永逸。

3. 从零搭建一条 Jenkins 测试流水线

3.1 设计流水线的几个原则

写 Pipeline 之前，我先说几条我踩过坑后总结出的原则：

第一，一个阶段只做一件事。Checkout 就只负责拉代码，别在里面顺便跑依赖安装；单元测试就只跑单测，别把部署也塞进去。阶段划分清晰，失败时看日志一眼就知道是哪个环节挂了，不用像查案一样从头翻。

第二，失败要前置、要快速。同样的代码问题，最好在单元测试阶段就暴露出来，而不是等构建镜像时才发现。所以测试执行顺序要讲究：对 CPU 消耗小、反馈最快的测试放前面，耗时长的放后面。

第三，测试产物必须归档。流水线跑完不只是为了得到一个绿灯，测试报告、JUnit 结果、覆盖率数据这些可以拿来辅助分析和复盘。用 Jenkins 的 Archive Artifacts 和 JUnit 插件把这些文件存下来，后面追问题就有据可依。

第四，部署环节必须加保险。测试流水线最终会触发部署，所以部署权限、目标环境的信息要单独管理，不能随便一个用户都能往生产环境推。我们的做法是：只有主干分支的构建才允许部署，功能分支跑完测试就结束，不给部署权限。

3.2 Pipeline 脚本逐段解析

给你看一个我在 Python 项目上实际用的 Pipeline 脚本（Declarative 风格），你可以直接复制改参数。涉及的业务是启动一个 FastAPI 服务，测试包含单元测试和接口测试：

pipeline { agent any environment { // GitLab 仓库地址 GIT_REPO = 'git@gitlab.example.com:backend/order-api.git' // Docker 镜像仓库配置 REGISTRY = 'registry.example.com' IMAGE_NAME = 'backend/order-api' IMAGE_TAG = "${env.GIT_BRANCH == 'main' ? 'prod' : 'dev'}-${env.BUILD_NUMBER}-${env.GIT_COMMIT.take(8)}" } options { timestamps() disableConcurrentBuilds() buildDiscarder(logRotator(numToKeepStr: '20')) timeout(time: 30, unit: 'MINUTES') } stages { stage('Checkout') { steps { checkout scm } } stage('环境准备') { steps { sh ''' python3 -m venv venv . venv/bin/activate pip install --upgrade pip pip install -r requirements-dev.txt ''' } } stage('单元测试') { steps { sh ''' . venv/bin/activate python -m pytest tests/unit -x --tb=short --junitxml=reports/unit.xml ''' } post { success { junit 'reports/unit.xml' } } } stage('代码质量检查') { steps { sh ''' . venv/bin/activate python -m pylint app --fail-under=8.0 python -m bandit -r app -b bandit.ini ''' } } stage('接口测试') { steps { sh ''' . venv/bin/activate python -m pytest tests/api --junitxml=reports/api.xml ''' } post { success { junit 'reports/api.xml' } } } stage('构建镜像') { when { expression { env.GIT_BRANCH == 'main' } } steps { sh ''' docker build -t ${REGISTRY}/${IMAGE_NAME}:${IMAGE_TAG} . docker push ${REGISTRY}/${IMAGE_NAME}:${IMAGE_TAG} ''' } } stage('部署测试环境') { when { expression { env.GIT_BRANCH == 'main' } } steps { sh ''' ssh deploy@192.168.1.20 "docker pull ${REGISTRY}/${IMAGE_NAME}:${IMAGE_TAG} && \ docker stop order-api || true && \ docker rm order-api || true && \ docker run -d --name order-api -p 8000:8000 \ -e DB_HOST=192.168.1.30 \ ${REGISTRY}/${IMAGE_NAME}:${IMAGE_TAG}" ''' } } } post { always { echo "构建结束，当前状态：${currentBuild.currentResult}" } failure { emailext ( to: 'backend-team@example.com', subject: "CI 构建失败: ${env.JOB_NAME} #${env.BUILD_NUMBER}", body: "请查看日志：${env.BUILD_URL}" ) } } }

逐个阶段解释一下设计思路。

Checkout 阶段不用多说了，Jenkins 根据源码管理配置拉取代码，checkout scm是声明式流水线的标准写法。

环境准备阶段创建 Python 虚拟环境并安装依赖。这里有个细节：依赖安装必须和测试分离。如果放在同一个阶段，一旦 pip 安装某个包特别慢，会拖累整个测试阶段的定位效率。而且虚拟环境路径要统一，避免后面多个阶段都去找绝对路径。

单元测试阶段执行 pytest，并把 JUnit 格式的报告归档。-x参数表示遇到第一个失败就停止，适合快速失败；--tb=short为了日志不要刷屏。post块里用junit命令让 Jenkins 收集测试报告，这样在构建详情页就能看到测试趋势。

代码质量检查阶段用了 pylint 和 bandit。pylint 的--fail-under=8.0意思是评分低于 8 分直接让构建失败，这就是一道质量门禁。bandit 是做 Python 安全静态检查的，很多团队的流水线没有这一步，但实际上把已知的路径遍历、SQL 注入风险在开发阶段拦截下来，成本远低于以后线上出问题再修。

接口测试阶段相当于把服务实际跑起来再测接口，比普通单测更接近真实链路。这里如果你测的是 HTTP 接口，通常还需要先在后台把服务进程拉起来，再执行 pytest，脚本可以按需补充。

构建镜像和部署两个阶段都加了when条件，只有 main 分支才执行。这是为了避免你在功能分支每次提交都产生一堆无意义的镜像和部署，同时也是为了安全：部署动作只允许主干触发。IMAGE_TAG 的生成规则dev-构建号-提交前8位保证每次构建的镜像都有唯一标识，后面出问题可以精确定位代码版本。

最后的post块定义了构建结束后的统一处理：不管成功失败都打日志；失败就发邮件通知。实际项目中我还会加上发包给企业微信或钉钉的脚本，把构建结果推送到即时通讯群，这样谁提交的代码挂了，群里一眼就能看到，不用等人发现。

3.3 Pipeline 写法的关键细节与经验

第一个要特别强调的坑是 Jenkinsfile 里的script块。Declarative 风格下，所有需要动态计算的逻辑都要包在script { }里，不要在 environment 区域做复杂的 Groovy 运算。上面那个 IMAGE_TAG 我用了简单的三元表达式没问题，如果你要写函数，建议放在代码块里调用。

第二个坑是when条件的写法。很多人会写成when { branch 'main' }，但实际上 GIT_BRANCH 的值可能是origin/main而不是main。我通常用expression { env.GIT_BRANCH == 'main' }这种精确判断，或者在分支命名有规范的情况下写成带origin/前缀的形式，这样不容易踩坑。

第三个坑是 Docker 构建环境。如果你的 Jenkins 没有挂载/var/run/docker.sock，到构建镜像阶段会报docker: command not found，或者报连不上 Docker daemon。解决方式就是挂载 socket；另外也可以用 Docker Pipeline 插件的docker.withRegistry()方式，把推送仓库的认证交给 Jenkins 凭证管理，而不是裸写在 shell 里。

4. 镜像构建与自动化部署实践

4.1 多阶段 Dockerfile 设计

流水线里构建镜像这一步，很多人一开始图省事，直接写一个简单的 Dockerfile 把运行环境依赖全部装进去。结果就是镜像体积动辄上 G，构建慢、传输慢、还暴露了很多不必要的操作系统工具。我推荐用多阶段构建。

以 Python 项目为例：

# 阶段一：构建环境 FROM python:3.10-slim AS builder WORKDIR /app COPY requirements.txt . RUN pip install --prefix=/install -r requirements.txt # 阶段二：运行环境 FROM python:3.10-slim WORKDIR /app COPY --from=builder /install /usr/local COPY . . ENV PYTHONUNBUFFERED=1 EXPOSE 8000 CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

这个 Dockerfile 的精髓在于两个阶段。第一阶段builder只负责安装 Python 依赖，把安装结果输出到/install目录；第二阶段运行环境只拷贝依赖和业务代码，不保留 pip 缓存、构建工具链这些运行时用不到的东西。最终镜像比单阶段构建能小 40% 到 60%，部署时拉取速度差异非常明显。

如果你还要进一步压掉体积，可以尝试把基础镜像换成python:3.10-alpine，但要注意 alpine 底层的 musl libc 有时会导致部分 whl 包编译不过，项目依赖如果有原生扩展，反而更折腾。所以我个人更推荐slim系列，平衡体积和兼容性。

4.2 镜像版本命名与推送策略

镜像 Tag 的命名看起来是个小事，但直接影响你部署和回滚的体验。我见过的比较合理的规则有这么几种：

• 按语义化版本：v1.2.3，适合有正式发版节奏的项目。
• 按分支 + 构建号：dev-123/main-456，方便区分环境。
• 按 Git 提交 SHA：1a2b3c4d，可精确还原代码，但不直观。
• 混合规则：分支-构建号-SHA前8位，既直观又可追溯。

上面 Pipeline 里我用的就是混合规则。推送之前记得先登录镜像仓库，在脚本里会是：

docker login registry.example.com -u $REGISTRY_USER -p $REGISTRY_PASSWORD docker push ${REGISTRY}/${IMAGE_NAME}:${IMAGE_TAG}

如果用的是 Harbor 作为镜像仓库，仓库里建议开启"不可变标签"策略，防止同一个 Tag 被覆盖。否则镜像被覆盖之后，线上出问题时想通过 Tag 还原到上一个版本的镜像，可能就找不到了。这是一个很容易被忽略、但事故频发的点。

4.3 部署到测试环境的两种常见方案

镜像推送完成之后，下一步就是部署。我这边用过比较多的方案有两种：SSH 远程执行脚本和 Kubernetes 滚动更新。

SSH 方式最直接，适用于用 Docker 单机部署的场景。Pipeline 里那段ssh deploy@192.168.1.20 "docker pull ... && docker stop ... && docker run ..."就是典型代表。这里有一个必须注意的点：写这种命令前，一定要先在 Jenkins 机器上测试过 SSH 免密登录。否则会卡在Host key verification failed或者密码输入这一步。测试方法：

ssh deploy@192.168.1.20 "echo ok"

如果提示需要确认 host key，就先把 host key 加到 known_hosts 里。很多流水线第一次部署失败都是这个原因。

Kubernetes 方案适合更大规模的测试环境。部署动作会变成更新 Deployment 的镜像 Tag，让 K8s 自动滚动更新 Pod：

kubectl set image deployment/order-api order-api=${REGISTRY}/${IMAGE_NAME}:${IMAGE_TAG} kubectl rollout status deployment/order-api

这里之所以推荐 rollout status 等待更新完成，是因为这样可以在流水线阶段就知道部署是否成功，而不是把错误留到测试人员报 bug 的时候才发现。加上健康检查探针后，Pod 启动异常会自动回滚，稳定性会好很多。

5. GitLab CI 也能做测试流水线：对比迁移指南

5.1 用 .gitlab-ci.yml 实现同一条链路

聊完 Jenkins，再提一提 GitLab CI。很多小团队在初期并不会单独部署 Jenkins，而是直接用 GitLab 自带的 CI/CD，因为真的太方便了。同样的测试流水线，用 GitLab CI 只需要在仓库根目录放一个.gitlab-ci.yml文件。

stages: - test - build - deploy variables: PYTHON_VERSION: "3.10" IMAGE_TAG: "$CI_COMMIT_SHORT_SHA" cache: key: "$CI_JOB_NAME-$CI_COMMIT_REF_SLUG" paths: - .cache/pip unit-test: stage: test image: python:${PYTHON_VERSION} script: - pip install -r requirements-dev.txt - python -m pytest tests/unit --junitxml=reports/unit.xml artifacts: paths: - reports/ expire_in: 7 days when: always tags: - docker build-image: stage: build image: docker:24 services: - docker:24-dind script: - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY - docker build -t $CI_REGISTRY_IMAGE:$IMAGE_TAG . - docker push $CI_REGISTRY_IMAGE:$IMAGE_TAG only: - main deploy-test: stage: deploy image: alpine:latest before_script: - apk add --no-cache openssh-client script: - ssh deploy@192.168.1.20 "docker pull $CI_REGISTRY_IMAGE:$IMAGE_TAG && docker run -d ..." only: - main environment: name: test

GitLab CI 的核心概念是 stages、job、runner。stages 定义了阶段顺序，job 是每个阶段里实际执行的任务，runner 是真正执行任务的 agent。管道由一个或多个 job 组成，各自可以指定运行在哪个 runner 上、用什么镜像、跑什么命令。

这段配置里值得注意的地方：unit-test 任务通过artifacts把测试报告保存下来，并且设置了expire_in: 7 days，避免报告堆积；build-image 用到了 Docker 官方推荐的 docker-in-docker（dind）服务，这是 GitLab CI 里构建镜像最常见的方案；cache 缓存了 pip 下载的包，能显著加快重复构建速度。

5.2 Jenkins 与 GitLab CI 的选型对比

两种方案我用过很久，做个客观的比较：

我的实际建议是，如果公司代码都在 GitLab，流程又偏标准，先直接用 GitLab CI 把流水线跑起来，成本最低。等到项目多了、流程复杂了，比如有多个团队要共享流水线模板、要接入各种私有工具链时，再考虑迁移到 Jenkins。迁移也不需要全部重写，把.gitlab-ci.yml的每个 job 映射为 Jenkins 的 stage 即可。

6. 常见问题排查与安全加固实录

6.1 高频报错速查表

搭这套流水线过程中，我遇到过不少报错，整理成速查表，排查时可以直接对照：

逐个说一下排查的关键点。

SSH 问题是最常见的，但也很容易自查。报Permission denied (publickey)时，先手动在 Jenkins 机器上执行ssh -T git@gitlab.example.com，如果 GitLab 返回Welcome to GitLab，说明私钥没问题，那问题大概率出在 Jenkins 凭证里的私钥和实际私钥不一致。这里要注意：Jenkins 凭证里的私钥必须是id_ed25519或id_rsa的完整内容，不能只复制公钥。

Host key verification failed的解决方式是在 Jenkins 机器上先用 deploy 用户或者当前用户手动 ssh 到 GitLab 一次，接受指纹，让 known_hosts 里有记录。或者更稳妥的做法是把 GitLab 的 host key 提前预置到 Jenkins 镜像里。

镜像构建报错那一条，如果你用的是 Harbor 私有仓库，最常见的原因是docker login只在阶段内执行，但后续步骤在新 shell 里执行，认证信息丢失。解决办法是：登录认证放进 before/环境准备阶段，并用docker login写配置后明确指定用这个仓库地址，不要每次构建都重新登录。

6.2 权限控制与安全加固实践

流水线跑起来以后，安全和权限是接下来必须补齐的功课。共享账号和裸奔权限是很多团队的通病，我强烈建议至少做到下面几点。

第一，最小权限原则。给 Jenkins 的 GitLab 机器人账号只开它需要的权限，比如 Pull 代码的权限、触发 CI 的权限，不要给 Owner 或 Maintainer。给流水线部署测试环境的账号，也不要拥有生产环境的操作权限。哪怕麻烦一点，多维护一两个账号，安全基线也完全不一样。

第二，Jenkins 的权限模型要配置。默认 Jenkins 是任何登录用户都能看到所有任务并执行，这在多人团队很危险。建议在 Jenkins 系统配置里开启"基于项目的矩阵授权策略"，给不同角色分配不同的 Job 执行和查看权限。比如测试开发可以执行流水线，但只有运维角色能修改流水线脚本，普通研发只能查看构建结果。

第三，GitLab 侧的安全加固。及时升级 GitLab 版本，官方修复高危漏洞时尽快打补丁；关闭开放注册，允许用户注册容易混入垃圾账号；如果团队人少，建议直接关闭注册入口，用管理员统一创建账号；由于 GitLab 各类敏感信息都在项目里，一定要让员工妥善保管 SSH 私钥和 Token，不要把 Token 提交到代码库。我见过太多仓库里藏着.env文件导致数据库密码泄露的事故了。

第四，流水线里的敏感信息不要硬编码。数据库密码、SSH 密钥、镜像仓库凭据，都要放到 Jenkins 的凭据管理或 GitLab CI 的变量里，通过${env.VAR}引用，不要直接写进 Jenkinsfile 或.gitlab-ci.yml。否则仓库一泄露，基础设施等于全部裸奔。

第五，审计日志和通知机制。GitLab 和 Jenkins 都有审计功能，建议开启并关注异常登录或异常执行记录；CI 失败推送通知一定要配好，不要让流水线的红灯挂了几天都没人管，那自动化就没有意义了。

我个人在搭建这些流水线时的最大体会是：先跑通最小闭环，再谈优化。很多团队一上来就想把所有质量门禁、灰度发布都塞进流水线，结果折腾一个月还没跑起来。其实最核心的就是拉代码、跑测试、构建镜像、部署测试环境这四步。先把这四步跑顺，后续加静态检查、覆盖率、安全扫描、通知机器人，都是顺手的事。等你有了第一条稳定的流水线，你会明显感觉到，团队交付的节奏和信心，完全不一样了。