别再让开发写 YAML 了：企业级“自助流水线市场”，才是 DevOps 的终局形态

说个扎心的现实：

很多公司搞了几年 DevOps，最后变成什么样？

• 每个项目一堆 .github/workflows/*.yml
• 或者 .gitlab-ci.yml 长得像一坨意大利面 🍝
• 新人入职第一件事：抄别人 CI 配置

你以为你在做“自动化”，
其实你在制造新的“技术债”。

今天我们聊点更高级、也更实在的东西：

👉 用 GitHub Actions / GitLab CI，构建一个“企业级自助流水线市场”

说白了就是一句话：

让开发不写 CI，只选 CI。

一、问题本质：CI 不应该是“手工活”

大多数团队的 CI 长这样：

# .github/workflows/build.yml
name: Build

on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Build
        run: mvn clean install

看起来挺简单，对吧？

但问题在于：

• Java 一个写法
• Python 一个写法
• Node 又一个写法
• 每个团队还会魔改一版

结果：

👉 重复造轮子 + 无法治理 + 安全不可控

这时候你就该意识到：

CI 不应该是“代码”，而应该是“产品”。

二、什么是“自助流水线市场”？

你可以把它理解成一个内部“应用商店”：

开发不再写 YAML，而是：

👉 选择一个模板 → 填参数 → 一键运行

三、第一步：把流水线“产品化”

👉 在 GitHub Actions 中的做法：Reusable Workflow

# .github/workflows/java-build.yml
name: Java Build Template

on:
  workflow_call:
    inputs:
      java_version:
        required: true
        type: string

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup Java
        uses: actions/setup-java@v3
        with:
          java-version: ${{ inputs.java_version }}

      - name: Build
        run: mvn clean install

👉 业务项目怎么用？

# .github/workflows/use-template.yml
name: Use Template

on: [push]

jobs:
  call-template:
    uses: org/repo/.github/workflows/java-build.yml@main
    with:
      java_version: '17'

看出来没？

👉 开发只需要填参数，不需要关心细节

四、GitLab CI：更适合“企业平台化”

GitLab 在这方面其实更“企业味”。

👉 用 include + template

# template: java.gitlab-ci.yml
.build_java:
  script:
    - mvn clean install

👉 项目引用

include:
  - project: 'platform/ci-templates'
    file: '/java.gitlab-ci.yml'

build:
  extends: .build_java

这时候你已经有“模板市场”的雏形了。

但注意：

👉 这还只是“技术实现”，还不是“产品”。

五、关键进阶：做成“真正的市场”

很多团队做到这里就停了，然后失败了。

为什么？

因为缺 3 个关键东西：

1️⃣ 模板分级（别一锅粥）

你必须像产品一样分层：

• 基础模板（编译 / 测试）
• 进阶模板（构建镜像 / 发布）
• 高级模板（灰度 / 回滚 / 蓝盾）

否则：

👉 模板越多 = 混乱越多

2️⃣ 参数标准化（核心中的核心）

如果你允许开发随便传参数：

👉 你就回到了“写 YAML”的老路

正确做法：

inputs:
  service_name:
    required: true
  env:
    required: true
    default: dev
    type: choice
    options:
      - dev
      - staging
      - prod

👉 限制选择，才能实现治理。

3️⃣ UI 层（决定成败）

说句大实话：

如果你让开发“写 YAML 调模板”，那就不叫自助市场。

你需要：

• 一个简单界面（甚至是内部平台）
• 下拉选择模板
• 填几个参数
• 点击运行

哪怕只是个简单 Web 表单 + API：

# 伪代码：触发 GitHub Actions
import requests

def trigger_workflow(repo, workflow, inputs):
    url = f"https://api.github.com/repos/{repo}/actions/workflows/{workflow}/dispatches"
    payload = {
        "ref": "main",
        "inputs": inputs
    }
    requests.post(url, json=payload)

这一步，才是“质变”。

六、为什么这是未来？

我说一个很直接的观点：

未来的 DevOps，不是“写 pipeline”，而是“运营 pipeline”。

你要关注的不是：

• CI 写得多优雅

而是：

• 有没有复用
• 有没有治理
• 有没有标准化
• 有没有降低认知成本

七、真实收益（不是 PPT）

我见过一个团队做完“流水线市场”之后：

🚀 效果是这样的：

• CI 配置量 ↓ 80%
• 新项目接入时间：2 天 → 30 分钟
• 安全漏洞：大幅减少（统一扫描）
• 运维从“救火队”变成“平台团队”

八、但别盲目上：有前提

不是所有公司都适合搞这一套。

你至少要满足：

• 有 20+ 项目
• 技术栈相对统一
• 有平台团队

否则：

👉 成本 > 收益

九、我自己的一个判断

这句话你可以记下来：

CI/CD 的终局，一定是“平台化 + 产品化 + 自助化”。

就像云计算一样：

• 从手动部署
• 到自动化
• 再到 Serverless

CI 也一样：

• 从写 YAML
• 到复用模板
• 再到“点按钮发版”

十、最后一句话（有点狠，但真实）

如果你的团队现在：

• 每个项目还在复制 .gitlab-ci.yml
• 出问题靠人肉排查
• 发版流程靠“经验”

那你们不是在做 DevOps，

你们只是：

👉 把手工活，变成了自动化的手工活。