企业官网建设流程全解析

1. 先看清一个矛盾：为什么提效和安全的账经常算不平

做CI/CD选型这件事，最怕的不是工具少，而是团队里每个人对"CI/CD到底要解决什么"的理解不一样。我见过不少团队，老板要的是发布更快，开发要的是少填表单，运维要的是出事了能追溯，安全那边则希望什么都别自动化。四拨人坐在一起选产品，选了三个月，最后选了个谁都不满意的。

这个矛盾说白了就一句话：交付变快和门禁变严天然互斥。每一道安全审批都在拉长交付链路，每一次自动化跳过又都在积累技术债。真正好的CI/CD产品，不是帮你把某一边做到极致，而是把这两边的"摩擦点"处理得足够平滑。这也是我写这篇评测的出发点——不堆功能清单，而是从"提效和安全怎么同时落地"的角度，把主流的流水线产品掰开揉碎讲清楚，给正准备选型或者正在改造流水线的团队一个可以直接拿走的参考。

先说一个很容易踩的坑：很多人搜"流水线"的时候，会把完全不同的东西混在一起。比如最近网络热词里有"dify知识库流水线""理想流水线cpu设计"，还有"gitlab docker engine ci/cd"——这三个"流水线"其实是三个物种。CPU设计里的流水线是芯片内部的指令并行技术，dify知识库里的流水线是AI应用的编排工作流，而CI/CD流水线是软件交付的自动化管道。名字都叫流水线，解决的问题完全不同。选型之前先把概念边界划清楚，能省很多无效沟通。

回到CI/CD本身，我发现一个普遍现象：很多团队的流水线只是把原来手点的按钮换成了自动触发的按钮，流程本身并没有变。原来要手动跑编译，现在流水线帮你跑；原来要手动传包，现在流水线帮你传。这确实是提效，但距离"安全与效率的平衡"还差得远。真正的平衡点在于：哪些环节必须保留人工判断，哪些环节可以完全自动化，哪些环节必须用机器强制卡死。这恰恰是选型最核心的决策依据，也是后面评测每款产品的核心视角。

1.1 默认的CI/CD配置只解决了"自动化"，没解决"安全性"

绝大多数流水线产品开箱即用的配置，重点解决的是"能不能跑起来"：代码推送触发构建、构建产物上传、通知结果。至于这台构建机是不是被植入了挖矿脚本、构建产物里的依赖有没有已知漏洞、部署时用的这枚密钥是不是已经泄露到公网仓库——默认配置统统不管。

这不是产品的锅，而是产品的定位使然。CI/CD工具的角色是"放大镜"，把你告诉它的规则放大执行到每一个提交上。规则本身安不安全，取决于你在这个工具里加了哪些卡点。所以评测一款CI/CD产品，我第一个看的就是"安全能力是原生提供的，还是要靠插件拼凑"，这两者的维护成本差的不是一点半点。

1.2 从"理想流水线CPU设计"想到的：流水线应该有数据依赖图，而不只是脚本串烧

热词里有"理想流水线cpu设计"，虽然说的是芯片，但思路对做CI/CD很有启发。CPU流水线之所以高效，是因为它清楚地知道每个指令阶段之间的数据依赖关系，哪个阶段必须等，哪个阶段可以并行，是由依赖关系决定的，不是拍脑袋定的。

回头看好多人搭的CI/CD流水线，本质就是一段从上到下执行的shell脚本，跟"用bash -c把所有事串起来"没有本质区别。一旦某个阶段失败，后面全挂；一旦某个阶段变慢，整个管道跟着慢。这其实是被当成流水线用的脚本，完全没发挥出流水线的能力。

好的流水线应该显式声明阶段依赖。比如单元测试跑完才能打包，这是真依赖，必须串行；而单元测试和代码扫描之间没有数据依赖，完全可以并行。我用过的产品里，有的把阶段并行做成默认行为，有的要自己写parallel关键字，光这一点就能看出产品设计水平的差异。后面评测的时候，我会把"是否容易编排并行与依赖"作为效率维度的重要指标。

2. 选型前，先回答三个问题再打开产品列表

每次有人问我"推荐哪个CI/CD工具"，我都会先反问他三个问题。不把这几个问题想清楚，直接看官网对比页，最后一定是被宣传话术带着走，选出来的工具用半年就难受。

2.1 你的团队是"自建派"还是"全托管派"

这是个路线之争，会直接影响后面所有的选型空间。自建派的意思是代码仓库、构建产物、部署目标全部在自己掌握的机器上，对应的是GitLab CI、Jenkins这类可以私有化部署的产品。好处是数据不出门，密钥管理在自家手里，安全策略可以做到很细；代价是构建机的资源你得自己掏、版本升级你得自己扛、坏了得有人半夜爬起来修。

全托管派则把代码托管、流水线执行、日志存储都交给云厂商，对应GitHub Actions、云效、CODING这类SaaS产品。好处是零运维成本，开箱即用，安全补丁由厂商更新，天然带审计日志；坏处是代码资产存在别人那里，有些行业合规上过不了，而且费用会随着用量非线性增长，月底对账单可能吓你一跳。

两条路线没有绝对好坏，但有适配场景。我见过最痛苦的转型，是本来团队只有5个人用了Jenkins，后面业务扩张到50人，维护成本直接失控。也见过团队为了数据安全选全自建，结果产品迭代速度被运维拖累到周更都费劲。选路线之前，把"未来两年团队规模、交付频率、合规要求"三个变量提前预测一下，比现在能用什么更重要。

2.2 瓶颈在"编译等待"还是"人肉上线"

你们团队现在的交付慢，到底慢在哪一步？这个问题的答案直接决定选型重点。

如果是编译构建太慢，比如一个大项目每次构建要跑40分钟，那你要关注的是产品的分布式构建缓存、增量编译支持、并行任务切分能力。GitLab CI的分布式缓存、Jenkins的pipeline分段、GitHub Actions的job矩阵，都在解决这一类问题。

如果是"代码早就写完了，但上线前要填一堆申请单、等审批、走变更窗口"，那瓶颈根本不在CI/CD工具上。你需要的其实是发布审批流和自动化部署结合的平台，像云效、CODING这类国内产品在"研发协同+审批流+发布"一体化上做得更顺手，纯Jenkins反而搞不定这种流程。这个问题想不清楚，就算把构建时间压缩到1分钟，整体交付速度也没变化，因为瓶颈在下游，不在上游。

2.3 安全投入的启动点是"还没出事"还是"已经被罚了"

安全这件事在CI/CD领域很容易被拖到最后一刻。未出事的团队普遍想法是：先把流程跑通，安全后面再加。出过事的团队才会意识到，代码仓库泄露一个密钥，比你想想中严重得多——攻击者会顺着密钥进你的构建机、摸你的生产环境、翻你的数据库，整个过程可能两周都没人发现。

我的建议是：不管选哪款产品，安全能力应该是选型的筛选条件，而不是后补条件。至少要保证然后在这几个维度上是合格的：

• 密钥是不是能跟代码仓库分开托管？
• 能不能做到"构建环境内看不到明文密钥"？
• 流水线的每一次执行有没有完整的审计日志？
• 能不能对接镜像漏洞扫描、依赖安全检查这类工具？

把这三个问题写在纸上，答案自然会把候选产品筛掉一半。剩下的一半，再进入下一节的横评环节。

3. 主流流水线产品横评：按团队形态对号入座

进入正题之前先说明一下，我没有条件把所有产品都在完全一致的压测环境里跑一遍，但过去几年我在不同团队里实打实用过这些产品，下面的评价全部基于实际使用体验，不是官网复制粘贴。评测维度就两个：提效能力和安全机制。

3.1 GitLab CI：仓库与流水线的一体化，git协作重度团队的省心之选

GitLab CI严格来说不只是一个CI/CD工具，它跟GitLab仓库深度绑定，配置直接写在仓库里的.gitlab-ci.yml文件，改配置就是改代码，天然有版本历史和MR评审。这一点非常加分，因为流水线本身也变成了"代码"，谁改了什么、为什么改，全部有记录，这本身就是安全合规的一部分。

效率上，GitLab CI的DAG并行依赖图是做得最好的之一，可以显式声明阶段之间的依赖关系，没有依赖的任务默认并行。实测下来，一个前后端分离项目，前端构建、后端构建、代码扫描三个任务并行，总耗时比原来的串行脚本缩短了接近一半。

安全性上，GitLab CI的受保护分支、受保护变量、审批门控都是原生功能，不用装插件。特别是Runner和Docker Engine结合的方式，每个job跑在独立的容器里，环境隔离做得很干净。热词里的"gitlab docker engine ci/cd"说的就是这个——用Docker executor跑job，构建环境影响最小化，job之间互不污染。我在第5节会专门演示这套配置。

唯一的槽点是：如果团队不用GitLab做代码托管，那GitLab CI的核心优势就没了。它跟GitLab绑定得太深，不是你仓库托管平台的GitLab CI，使用体验会打很多折扣。

3.2 Jenkins：生态全、存量多，但是一台不断积灰的"老车"

Jenkins在CI/CD领域就像行业里的老牌平台，插件生态没有对手，从代码编译到K8s部署，什么都能接。如果是维护多年的老项目，几百个构建任务都挂在Jenkins上，迁移成本高到不敢想——这种情况我一般不建议立刻替换，先把Jenkins上欠的安全账补上更实际。

但要说"提效安全双平衡"，Jenkins确实是几款里最吃力的。第一，安全能力几乎全靠插件拼。凭证管理要靠Credentials插件，扫描要靠SonarQube插件，门禁要自己写Pipeline脚本判断，每一块都能用，但每一块都要自己维护。第二，默认配置的安全性堪忧。默认开放的端口、默认的管理员账号、默认没有审计日志，很多团队Jenkins装好就忘了加固。我见过不止一次Jenkins暴露在公网、没有任何访问控制的情况，这等于把自家构建机的钥匙挂在门口。

如果你已经重度依赖于Jenkins，我的建议不是换掉，而是先把这几件事补上：启用RBAC权限矩阵、所有凭证改用Credentials插件统一管理、构建机出网收敛为白名单、Pipeline产物至少存留90天。这些是Jenkins最便宜的"安全补丁"。

3.3 GitHub Actions：上手最快，但成本像一个会膨胀的气球

GitHub Actions'最大的魅力是生态和市场效应，整个GitHub上有海量的现成action，从部署到通知，一句uses: xxx/xxx-action@v4就能引入。对个人开发者和小团队来说，它的上手体验几乎没有对手。

但放到"安全和效率双平衡"的框架下看，GitHub Actions有个很现实的问题：安全责任完全在用户一侧。它本质是把你.yaml里定义的steps放到GitHub的临时容器里执行，每一步用的action都来自第三方，你根本不知道别人的action代码里藏了什么。供应链投毒在GitHub Actions生态里已经出过不止一次的事故——有名气的action被维护者自己塞了后门，或者仓库被盗后恶意提交。用第三方action之前，你至少得读一遍它的源码，这对小团队来说成本太高了。

收费上也是，公开仓库免费，私有仓库按分钟计费，大项目跑满的时候账单涨得很快。个人项目和小团队玩玩可以，企业级严肃交付场景，我建议慎选。

3.4 云效、CODING：国内全托管路线的选择，合规和审批流是强项

云效和CODING代表的是"研发协同+流水线一体化"的路线，价格相对透明，天然适配国内团队的合规要求。

安全机制上，这俩的亮点在"跟阿里云/腾讯云的账号体系打通"。密钥可以放在云端机密管理里，流水线执行时通过临时凭证注入，构建机器上不落明文密钥，这一点比很多自建方案做得聪明。另外，发布审批流是原生能力，可以做到"环境级别审批"，比如测试环境自动部署、生产环境必须指定负责人通过才能继续。这对中大型团队的处理审批流程是很大的提效，因为审批动作和流水线状态是联动的，不是发个消息等回复。

效率上，云效的流水线编辑界面可视化程度高，跟代码库、制品库、K8s集群都是云上打通，部署目标配置起来比Jenkins简单太多。CODING的制品库和项目协同一体化也做得不错。如果是纯国内团队、没有强制数据必须留在本地的要求、又不太想花精力运维自建系统，我会推荐从这两个里选。但如果你的团队已经有了自建的代码托管和K8s集群，强行平移到云厂商体系反而是折腾。

3.5 轻量方案：Drone、GoCD，以及重点说下Docker executor的选择

除了上面几款主流外，还有一些精准玩家值得一提。Drone主打轻量、容器化，跟Docker结合得好，配置简单，适合方向明确的小团队；GoCD则把"部署流水线"的模型做得非常深刻，可追溯性很强，适合对部署流程有严格要求但不想用重型平台的团队。

这里重点聊一下热词里反复出现的"gitlab docker engine ci/cd"到底该怎么选。GitLab Runner支持好几种执行器，其中最常用的是shell和docker。shell执行器直接跑在Runner机器上，速度快，但job之间共用同一台机器环境，一个job装了新的依赖或者改了全局变量，下一个job会以被污染的环境运行，排错能排到你怀疑人生。

docker执行器才是正解。每个job起一个干净的容器来执行，镜像拉取、依赖安装、构建转译全部在容器内完成，job结束容器销毁，环境彻底隔离。我实测过从shell切到docker执行器之后，以前"本地能过、CI挂了"的玄学问题少了八九成，因为环境一致性问题从根本上被解决了。代价是每次都要拉镜像，这里有坑：如果镜像拉取策略没配好，每个job都重新拉一遍大镜像，耗时直接翻倍。解决方案是把基础镜像改成小体积的alpine系镜像，并给Runner配置好镜像缓存策略。

4. 安全实际上卡在细节里：不只是权限角色那点事

很多人理解CI/CD安全，就以为是三个词：权限、权限、还是权限。确实，如果所有人都能随便跑流水线、随便改流水线配置，那提效做得越好系统崩溃越快。但比权限更要命的是另外几个细节，这几个细节我在第3节里已经点了名，这里展开细说。

4.1 密钥托管：明文密钥进了构建日志，基本等于裸奔

我接手过一个团队的历史包袱：数据库密码、云厂商AK/SK、生产服务器密钥，全都以明文变量的形式写在Jenkins任务配置里。表面看功能能跑，但只要任何一个能查看构建日志的人，就能看到构建时打印的密钥。更可怕的是这些密钥散落在各个人头里和聊天记录里，两年没轮转过了。

安全第一课，就是把所有密钥收拢到专用的凭证管理机制中。GitLab CI用受保护变量，在runner执行时注入环境器，但注入之后你还得确保看不到它——应用里顺手echo $password打印一顿，等于自己又把门打开。Jenkins用Credentials插件统一管理，密钥以****形式存储在内部，在Pipeline里通过withCredentials注入，构建日志里不会暴露。"密钥只看得到引用，看不到本身"，这个原则做没做到位，需要替换尽在第一时间验证。

注意：改完密钥托管之后，立刻把所有旧的密钥全部轮转一遍。这不但是成本最低的安全加固，也是验证你这次改造有没有做漏的关键动作。

4.2 依赖锁定与镜像扫描：供应链攻击的无声入口

CI/CD流水线每天都在重复一件事：拉依赖、装依赖、构建镜像。这意味着，供应链攻击可以非常轻松地潜伏在每一次自动构建里。热门开源包被恶意发布新版本、旧版本被删除后在镜像里留下无法追溯的嫌疑代码，这类事件这几年时有发生。

对策前置到流水线里，核心是两件事。第一，构建阶段就锁依赖：前后端项目统一用lockfile（package-lock.json、pnpm-lock.yaml、go.sum、requirements-lock）锁定版本，禁止"每次构建拉最新版"的裸奔做法；第二，镜像构建前加扫描阶段：Harbor/Trivy这类工具扫描基础镜像和依赖的已知漏洞，发现高危漏洞就fail整个流水线。

有人嫌扫描阶段拖慢构建时间。我的实测是，Trivy扫描一个中等规模镜像，首次全量扫描可能1~2分钟，但配置了缓存之后增量扫描基本在10秒内结束，对交付效率的影响微乎其微——用这点时间换一次"上线后才发现容器里有CVE-2024-xxxx"的灾难，非常划算。

4.3 不可变构建记录与审计：出事的时候能说清楚"谁，什么时候，改了什么"

真正出事的时候，CI/CD工具最容易被挑战的就是"追溯能力"。比如生产环境出了一个诡异的问题，运维说"最近没动过啊"，开发说"我上个版本没改这块逻辑"，两边都拿不出硬证据。这时候如果流水线没有完整的不可变构建记录，这个锅就怎么都甩不干净了。

好的CI/CD产品，至少要做到每个构建产物都对应一个不可变的ID，记录代码commit、构建参数、触发人、审查人、产物哈希。这个ID从构建开始一直到线上部署，全程透传。GitLab CI和GitHub Actions在这一点上做得比较原生，Jenkins需要自己规整产物命名规则。

实际操作的时候，我习惯在产物里加一个build.info文件，里面写明commit SHA、构建时间、构建者、依赖锁文件哈希、镜像tag。这样就算产品出了事，拉到线上容器里直接读这个文件，两分钟之内就能定位到对应的流水线执行记录。别小看这个细节，在出大事故的时候，它就是救命的证据链。

5. 我的实测：给若依部署做一条带门禁的流水线

上面的横评和原理说了这么多，最终还是要落地。这一节我用一个很常见的实战场景——若依后台管理系统部署CI/CD，用GitLab CI + Docker executor组合，完整搭建一条"效率和安全双平衡"的流水线。这里面每一步都是我实际跑过的，直接照着操作基本能复现。

5.1 跑起来之前的环境准备

我这次的实验环境是这样：一台4核8G的服务器，装好Docker和GitLab Runner；项目是常见的Java前后端分离结构——后端Spring Boot、前端Vue，对应若依这种开源脚手架典型的形态。代码托管在自建GitLab上。

安装GitLab Runner之后，先做注册。注册命令里最关键的两个参数是--executor docker和--docker-image，前者让Runner用Docker执行器，后者指定每个job跑的默认容器镜像。我把Java构建镜像和Node构建镜像的准备放进前置脚本，确保后端job、前端job各用各的容器，彼此不干扰。

5.2 配置.gitlab-ci.yml：阶段划分与卡点设置

下面是核心的流水线配置，按顺序分成compile、test、scan、image、deploy五个阶段。实际跑下来的效果，前端和后端在compile阶段并行，扫描在test阶段并行，总耗时比原来写一个巨型shell脚本快了一大截：

stages: - compile - test - scan - image - deploy backend-compile: stage: compile image: maven:3.8-openjdk-11 script: - ./mvnw clean package -DskipTests artifacts: paths: - target/*.jar expire_in: 1 day frontend-compile: stage: compile image: registry.cn-hangzhou.aliyuncs.com/xxx/node:18-alpine script: - npm config set registry https://registry.npmmirror.com - npm ci - npm run build artifacts: paths: - dist/ expire_in: 1 day

npm ci这一行值得说一下。国内团队跑前端构建，很多人习惯npm install，但install会更新package-lock.json，这等于楼依赖锁定形同虚设。npm ci是严格按照lockfile安装，装不上就报错，从源头保证这次构建依赖的一定是锁定的版本。

test阶段我用内置的单元测试，scan阶段通过两个job并行跑：一个用Trivy扫描后端依赖目录，一个跑前端安全审计。

backend-scan: stage: scan image: aquasec/trivy:latest script: - trivy fs --severity HIGH,CRITICAL --fail-on-severity HIGH --exit-code 1 .

--exit-code 1 --fail-on-severity HIGH的意思是：只要发现有HIGH及以上级别漏洞，这个job就返回失败码，流水线直接在这里断掉。这就是"自动化的安全卡点"，不用人工review依赖，机器判断音量最狠也最公正。这个卡点配合"生产分支受保护、MR必须通过流水线才能合并"的设置，安全性和效率同时兼顾了。

5.3 Docker executor的两个实战坑

跑这套流水线的过程中，我踩了两个非常典型的坑，都在Docker executor相关的位置。

第一个坑是缓存目录不持久。Docker执行器每个job都从干净容器开始，默认没有挂载缓存，导致每次构建都要重新下载依赖。Maven构建下载几百兆依赖，耗时直接爆炸。解决方案是给Runner挂上持久化的缓存Volume，GitLab Runner的config.toml里加volume挂载，把~/.m2和~/.npm缓存到宿主机。加上之后，二次构建速度提升非常明显。

第二个坑是镜像拉取策略策略默认总是pull。如果你的私有镜像仓库里的标签是latest，Runner会在每个job启动时去拉最新版，万一镜像仓库账号密码配置不对，job直接卡在拉取阶段。我的建议是，基础镜像全用带具体版本的tag（比如node:18-alpine而不是node:latest），同时Runner的镜像拉取策略根据实际情况采用if-not-present，避免不必要的网络折腾。

5.4 部署阶段的审校门禁设计

流水线走到部署阶段，密码安全要继续把关。我把连接服务器需要的SSH私钥全部放进GitLab的受保护变量，在deploy job内通过$SSH_PRIVATE_KEY引用。这里有个经验：尽量把部署动作写在target主机的本地脚本里，流水线只承担"把产物传到目标机并触发脚本"的责任。这样生产主机上的操作细节不全都暴露在流水线代码里，减少了安全面。

生产环境的部署，我设置成"手动触发"，在GitLab CI里给deploy job加上when: manual，并配了受保护环境标记：

deploy-production: stage: deploy environment: production when: manual script: - echo "deploying..."

environment: production配合GitLab的受保护环境，意味着只有配置了对应权限的Maintainer或者指定的部署人才能真正启动这个job，其他角色的开发者就算能跑到最后一个阶段，按钮依然是灰的。这比很多团队在CD工具外面配一套审批系统要轻量得多，效果却一点不打折。当自动化做到位之后，这里的手动动作就是"安全与效率"之间的合理减速带——它不是让交付变慢，而是确保过错不至于一路自动冲进生产环境。

整套流水线全部跑通后，我把构建日志、扫描记录、部署记录截图留档，然后直接关掉了之前那套"主要靠人记"的离线发布文档。后续团队再发版，只需要：推送代码到主干 -> MR机器人评价 -> 流水线自动跑通编译测试扫描 -> 部署人确认生产环境按钮 -> 完事。原来发布一个版本要工程师亲自守着看日志，现在只需要花两分钟点一下确认。这个提效是真实的，安全发现也真的给交付链路上了一层硬保险。

6. 选型决策清单与最后的个人体会

评测写到最后，回到开头那句话：没有一款CI/CD工具适合所有人。为了帮你把这篇文章转化成实际的决策行动，我把所有提到的产品按"提效能力、安全机制、团队适配、迁移成本、运维成本"五个维度做一个打分表供参考。打分基于我实际使用体验和社区大量真实反馈，不同团队评分可能会有出入，重点看相对差距：

整理下来，我的选型建议其实指三句话：

第一，不用为了"提效"去追求全自动部署。发布动作保留一点"人工确认"的路程，对大多数中大型团队不是坏事，它形成的门禁能挡住非常多的误操作。真正的效率瓶颈从来不是那一次点击，而是每轮提交要拉长全链路的时间。

第二，选型的安全考察，重点看"密钥托管、供应链扫描、审计追溯、门禁审批"这几个硬指标，其他的花哨安全功能看看就好。这四项如果产品原生支持，后续的安全改造会非常顺；如果全要自己搭插件，维护成本会不断渗透到日常。

第三，落地顺序上，先做依赖锁定和镜像扫描，再谈密钥统一，最后才是复杂审批流。前两个是"拦住坏人"，审批流是"规范自己人"，顺序搞反了，你的流水线会变成一条又慢又难用的摆设。

我在实际使用中的体会是，CI/CD工具选型更像是一个长期演进的过程，不是一次性决定终身。最好的状态，是流水线能让你把"不敢自动化的环节"一个一个變成"可以自动化"，同时每自动化一步，安全卡点也随之增加一步。两者交替向前，交付链路才会越来越短，同时越来越稳。希望这篇基于真实使用经验的评测，能帮你少走我走过的弯路。