单文件级持续集成：多独立脚本/配置文件的独立部署方案咨询

当然有成熟的解决方案！核心思路就是基于文件变更的范围，触发对应的部署流水线，主流CI/CD工具都支持这类场景，刚好能解决你单仓库多独立组件的痛点。下面给你拆解几种常用方式：

1. 利用CI/CD工具的内置路径过滤功能 #

这是最直接的方案，几乎所有主流工具（GitHub Actions、GitLab CI、Jenkins等）都提供了路径匹配的过滤规则，让只有指定路径文件变更时，才执行对应的部署任务。

比如在GitLab CI里可以这么写：

# 仅当scriptA.sh或其部署脚本变更时，执行scriptA的部署
deploy-scriptA:
  stage: deploy
  script:
    - ./deploy-scriptA.sh
  only:
    changes:
      - scriptA.sh
      - deploy-scriptA.sh

# 仅当sourceB目录下的文件变更时，执行sourceB的部署
deploy-sourceB:
  stage: deploy
  script:
    - ./deploy-sourceB.sh
  only:
    changes:
      - sourceB/**/*

GitHub Actions里的写法类似，用paths和if条件控制：

jobs:
  deploy-scriptA:
    runs-on: ubuntu-latest
    if: contains(github.event.head_commit.modified, 'scriptA.sh') || contains(github.event.head_commit.modified, 'deploy-scriptA.sh')
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy-scriptA.sh

  deploy-sourceB:
    runs-on: ubuntu-latest
    if: startsWith(github.event.head_commit.modified, 'sourceB/')
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy-sourceB.sh

这种方式的好处是配置简单，不需要额外写脚本，工具会自动帮你判断变更范围。

2. 自定义变更检测脚本 #

如果工具的内置过滤不够灵活（比如需要复杂的匹配规则），可以自己写脚本通过git命令判断哪些文件发生了变更，然后触发对应的部署。

比如写一个Shell脚本deploy-trigger.sh：

#!/bin/bash

# 获取本次提交变更的文件列表
CHANGED_FILES=$(git diff --name-only HEAD^ HEAD)

# 检测scriptA相关文件是否变更
if echo "$CHANGED_FILES" | grep -E "^scriptA.sh$|^configs/scriptA/" ; then
  echo "Detected changes in scriptA, starting deployment..."
  ./deploy-scriptA.sh
fi

# 检测sourceB相关文件是否变更
if echo "$CHANGED_FILES" | grep -E "^sourceB/" ; then
  echo "Detected changes in sourceB, starting deployment..."
  ./deploy-sourceB.sh
fi

# 处理公共依赖变更（比如shared目录下的文件）
if echo "$CHANGED_FILES" | grep -E "^shared/" ; then
  echo "Detected changes in shared dependencies, deploying all components..."
  ./deploy-scriptA.sh
  ./deploy-sourceB.sh
fi

然后在CI流水线里执行这个脚本即可，这种方式灵活性更高，能应对各种复杂的变更判断场景。

3. 规范仓库的组件化目录结构 #

先把不同的独立组件整理到专属目录下，让仓库结构更清晰，也能让路径过滤更精准。比如：

project-root/
├── scriptA/
│   ├── scriptA.sh
│   ├── configs/
│   └── deploy.sh
├── sourceB/
│   ├── main.conf
│   ├── utils/
│   └── deploy.sh
└── shared/
    ├── common.sh
    └── global.conf

这样不管是用工具内置过滤还是自定义脚本，都能很方便地用scriptA/**/*这种路径匹配规则，避免因为文件散放导致的判断混乱。

4. 基于提交信息或标签的触发 #

如果团队有严格的提交规范，也可以通过提交信息里的关键词或者标签来触发特定组件的部署。比如约定提交信息包含[deploy-scriptA]时，就只部署scriptA；或者给scriptA的提交打标签scriptA-v1.2.0，触发对应的部署流水线。

不过这种方式依赖团队成员的执行规范，适合对路径过滤有特殊需求的场景。

额外注意点 #

• 要考虑公共依赖变更的情况：如果shared目录下的公共文件被修改，可能需要触发所有组件的部署，记得在过滤规则里加上对应的路径。
• 测试环节也要对应优化：比如只修改scriptA时，只运行scriptA的相关测试，不用跑全量测试，能节省CI资源和时间。

内容的提问来源于stack exchange，提问作者Javier S