公司有 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 依然可以非常清爽。