公司有 Go、Java、Python、Node？别慌：一套 CI/CD 标准化策略就够了
很多公司一开始做 CI/CD 的时候，场面其实挺“热闹”。
团队 A 用 Java + Maven
团队 B 用 Python + Poetry
团队 C 用 Node.js + npm
团队 D 用 Go + Makefile
最后 CI/CD 平台上就变成了一个“技术动物园”。
每个项目的流水线都长这样：
项目A → Jenkinsfile(1000行)
项目B → GitLab CI (另一套逻辑)
项目C → 手写Shell脚本
项目D → Makefile + Docker
刚开始大家都觉得：
“挺灵活的。”
但半年之后，运维团队就会开始怀疑人生：
- CI/CD维护成本越来越高
- 新项目接入要改一堆脚本
- 线上发布流程不统一
- 出问题没人知道是哪一步炸了
说白了就是一句话：
CI/CD 没有标准化。
今天咱就聊聊一个非常现实的问题：
当公司技术栈五花八门时，CI/CD 怎么统一？
答案其实很简单：
统一流程，不统一语言。
一、CI/CD 标准化的核心思想
很多人理解错了一件事。
他们觉得 CI/CD 标准化是：
所有项目必须用同一种技术栈
这基本是不可能的。
正确做法是：
统一流水线结构
允许不同构建方式
简单说就是：
代码 → 构建 → 测试 → 制品 → 镜像 → 部署
不管你是：
- Java
- Go
- Python
- Node
流程都必须一样。
我们一般会把 CI/CD 分成 五个标准阶段：
1 代码检查
2 构建
3 测试
4 镜像构建
5 部署
所有项目都必须遵循这个结构。
二、流水线模板化：CI/CD 标准化的关键
如果每个项目都自己写 pipeline，那标准化肯定做不起来。
最好的办法是：
提供 CI/CD 模板。
举个例子。
GitLab CI 模板
公司可以提供一个 统一 pipeline 模板：
stages:
- lint
- build
- test
- docker
- deploy
include:
- project: devops/pipeline-template
file: base.yml
项目只需要继承模板。
三、语言差异怎么处理？
这时候有人会问：
Java 和 Go 的构建方式完全不同，怎么统一？
答案是：
抽象构建接口。
我们一般会统一一个构建入口：
make build
每个项目只要实现这个接口。
例如：
Go 项目
build:
go build -o app main.go
Java 项目
build:
mvn clean package
Node 项目
build:
npm install
npm run build
这样 CI/CD 流水线只需要执行：
make build
就完成了构建。
流水线完全不需要关心语言。
四、Docker 才是多语言 CI/CD 的“统一语言”
说句实话。
CI/CD 真正统一世界的东西，其实是 Docker。
因为无论你是什么语言，最后部署的都是：
Docker Image
所以我们通常会统一一个标准镜像构建流程。
例如：
docker-build:
stage: docker
script:
- docker build -t registry/app:$CI_COMMIT_SHA .
- docker push registry/app:$CI_COMMIT_SHA
每个项目只需要提供一个 Dockerfile。
Go 服务 Dockerfile
FROM golang:1.21 as builder
WORKDIR /app
COPY . .
RUN go build -o app
FROM alpine
COPY --from=builder /app/app /app
CMD ["/app"]
Java 服务 Dockerfile
FROM openjdk:17
WORKDIR /app
COPY target/app.jar app.jar
CMD ["java","-jar","app.jar"]
Python 服务 Dockerfile
FROM python:3.11
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python","app.py"]
CI/CD 不需要知道语言。
只需要：
docker build
docker push
五、部署阶段必须彻底标准化
很多公司 CI/CD 最大的问题，其实出在 部署阶段。
有些服务用：
kubectl apply
有些用：
helm
有些甚至是：
ssh + shell
这种情况运维基本没法维护。
比较好的做法是：
统一 Helm 或 GitOps。
例如：
Helm 部署
deploy:
stage: deploy
script:
- helm upgrade --install app chart/ \
--set image.tag=$CI_COMMIT_SHA
这样每个服务部署方式都一致。
六、再往前走一步：CI/CD 平台工程化
当公司服务达到：
50+
100+
200+
CI/CD 不能再靠脚本堆。
这时候要做一件事：
平台工程（Platform Engineering）
例如提供：
- CI 模板库
- 构建镜像
- 统一发布工具
- 发布审批流程
- 自动回滚机制
甚至可以做一个 内部发布 CLI：
deploy service-a --env prod
CLI 背后其实就是调用：
CI/CD + Kubernetes + Helm
开发体验会好很多。
七、我踩过的一个 CI/CD 大坑
我以前在一个团队见过一个特别离谱的事情。
公司有 40多个服务。
结果每个服务：
Jenkinsfile 都不一样
有的 200 行。
有的 800 行。
最后 Jenkins 升级一次插件。
20 多个 pipeline 全挂。
运维团队花了三天才修好。
从那之后我们做了一件事：
所有 Jenkinsfile 不允许超过 20 行。
逻辑全部放模板。
后来维护成本直接下降了一半。
八、CI/CD 的终极目标不是自动化
很多人以为 CI/CD 的目标是：
自动部署
其实不是。
真正的目标是：
让团队协作更稳定。
当 CI/CD 做好之后：
开发会发现：
提代码 → 自动测试
合并代码 → 自动构建
发版本 → 自动部署
整个流程非常顺滑。
这时候 CI/CD 才算真正成功。
最后说一句真心话
很多公司在 CI/CD 上花了很多时间研究：
Jenkins vs GitLab CI
ArgoCD vs Flux
Tekton vs Drone
但其实最重要的从来不是工具。
而是三件事：
流程标准化
构建接口统一
部署方式统一
只要这三件事做好。
哪怕团队有：
- Go
- Java
- Python
- Node
- Rust
CI/CD 依然可以非常清爽。
