当前位置：首页 > news >正文

DeOldify与GitHub CI/CD集成：自动化测试与镜像构建流水线

news 2026/3/26 18:36:12

DeOldify与GitHub CI/CD集成：自动化测试与镜像构建流水线

最近在折腾一个老照片上色的项目，用的是DeOldify。这东西效果确实不错，但每次改点代码，都得手动跑测试、打包镜像，再上传到服务器部署，一套流程下来，半天时间就没了。要是赶上模型更新或者修复个bug，重复劳动更是让人头疼。

后来我就琢磨，能不能把这套流程自动化？代码一提交，测试自动跑，镜像自动打，最好还能自动更新到部署环境。正好GitHub Actions和星图GPU平台的API都能用上，就试着搭了一套流水线。用下来发现，效率提升不是一点半点，现在团队里的小伙伴提交代码也更有底气了。

这篇文章，我就来分享一下怎么把DeOldify的代码管理、模型测试和Docker镜像构建，跟GitHub Actions的自动化流水线结合起来。核心目标就一个：让代码从提交到可部署，全程无需人工干预，真正解放开发者的双手。

1. 为什么需要自动化流水线？

在聊具体怎么做之前，我们先看看手动操作有哪些麻烦。

手动流程的痛点：

效率低下：开发者需要记住一长串命令，依次执行代码检查、单元测试、模型推理测试、构建Docker镜像、推送镜像、最后再手动部署。任何一个步骤出错，都得从头再来。
环境不一致：“在我机器上是好的”成了经典难题。本地环境、测试环境、生产环境的细微差异，可能导致模型效果天差地别。
反馈延迟：代码提交后，可能要等到下次手动测试或部署时，才能发现潜在问题，修复成本变高。
流程不透明：团队其他成员不清楚某次提交是否经过了完整测试，镜像版本是否最新，容易引发协作混乱。

自动化流水线带来的价值：

提效：代码推送后，流水线自动触发，开发者可以立刻转向下一个任务。
一致性：流水线在干净、统一的环境中运行所有任务，确保了“构建一次，到处运行”。
快速反馈：任何导致测试失败或构建错误的提交，都会立即通知提交者，便于快速定位和修复。
可追溯：每一次成功的构建都会产生一个带有唯一标签的Docker镜像，并且与特定的代码提交关联，部署和回滚都变得非常清晰。

对于我们这个DeOldify项目来说，自动化测试尤其重要。因为这不光是普通的代码逻辑测试，还涉及到模型推理效果的验证——确保我们的修改不会把一张彩色照片“修复”成黑白片。

2. 整体方案设计

我们的目标是搭建一条从代码提交到生成可部署镜像的完整流水线。整个方案主要依托两大平台的能力：

GitHub / GitHub Actions: 负责代码托管、自动化工作流的编排与执行（运行测试）。
星图GPU平台: 提供强大的GPU算力，用于运行需要GPU的模型测试，并通过其API服务完成Docker镜像的自动构建与托管。

下面是整个流水线的运作流程图：

graph TD A[开发者推送代码到GitHub] --> B(触发GitHub Actions工作流); B --> C{执行CI阶段}; C --> C1[代码质量检查]; C --> C2[单元测试]; C --> C3[模型推理测试<br>（需GPU）]; C3 -- 测试通过 --> D{执行CD阶段}; D --> D1[准备Docker构建上下文]; D --> D2[调用星图平台API构建镜像]; D --> D3[镜像推送至星图仓库]; D3 --> E[生成带版本标签的镜像]; E --> F[通知团队构建成功]; C1 -- 失败 --> G[立即失败，通知开发者]; C2 -- 失败 --> G; C3 -- 失败 --> G;

流程关键点解析：

CI（持续集成）阶段：在代码合并前，自动验证代码质量。对于DeOldify，我们加入了模型推理测试，这是一个需要GPU资源的步骤。我们利用星图平台提供的GPU环境来运行这部分测试。
CD（持续交付）阶段：当所有测试通过后，自动将代码打包成Docker镜像。这里我们直接调用星图GPU平台的镜像构建API，将构建任务交给平台完成，无需自己维护构建服务器。构建好的镜像会直接推送到平台内的私有仓库，方便后续一键部署。

接下来，我们分步拆解如何实现这个方案。

3. 项目结构与测试准备

要让自动化跑起来，首先得把项目结构理清楚，并把测试写到位。

3.1 DeOldify项目结构适配

一个典型的、适合CI/CD的DeOldify项目目录可能如下所示：

deoldify-project/ ├── .github/ │ └── workflows/ │ └── ci-cd-pipeline.yml # GitHub Actions 工作流定义文件 ├── src/ # 源代码目录 │ ├── deoldify/ │ │ ├── __init__.py │ │ ├── data_loader.py │ │ ├── model.py # 模型定义 │ │ └── visualize.py │ └── test_input.jpg # 用于推理测试的样例老照片 ├── tests/ # 测试目录 │ ├── __init__.py │ ├── test_unit.py # 单元测试 │ └── test_model_inference.py # 模型推理测试 ├── Dockerfile # 用于构建最终部署镜像 ├── requirements.txt # Python依赖 ├── inference_api.py # 一个简单的FastAPI推理服务入口 └── README.md

关键文件说明：

Dockerfile: 定义了如何将我们的代码和环境打包成镜像。它应该包含基础环境（如Python、CUDA）、项目依赖安装、以及启动命令。
requirements.txt: 明确列出所有Python包依赖及版本，确保环境可复现。
inference_api.py: 一个简单的Web服务，这样构建出的镜像可以直接运行并提供上色API。
tests/: 存放所有测试用例，是自动化的质量守门员。

3.2 编写关键测试用例

自动化流水线的信心来源于测试。我们需要两类测试：

1. 单元测试 (tests/test_unit.py):检查工具函数、数据预处理等纯代码逻辑。这部分测试不依赖模型，可以在无GPU环境下快速运行。

# tests/test_unit.py 示例 import unittest from src.deoldify.data_loader import preprocess_image class TestDataLoader(unittest.TestCase): def test_preprocess_image_shape(self): # 模拟一个图像数据 dummy_image_data = ... processed = preprocess_image(dummy_image_data) # 断言处理后的图像尺寸符合模型输入要求 self.assertEqual(processed.shape, (256, 256, 3)) def test_preprocess_image_normalization(self): dummy_image_data = ... processed = preprocess_image(dummy_image_data) # 断言像素值已被归一化到正确范围 self.assertTrue(processed.min() >= 0.0) self.assertTrue(processed.max() <= 1.0) if __name__ == '__main__': unittest.main()

2. 模型推理测试 (tests/test_model_inference.py):这是核心。我们需要验证模型加载是否正常，并且对一张已知的老照片能产生合理的上色结果。这个测试需要GPU。

# tests/test_model_inference.py 示例 import unittest import numpy as np from PIL import Image import sys sys.path.append('src') # 假设我们有一个加载和运行模型的工具函数 from model_utils import load_model, run_colorization class TestModelInference(unittest.TestCase): @classmethod def setUpClass(cls): """在所有测试开始前，加载一次模型（耗时操作）""" cls.model = load_model('artistic') # 加载艺术风格模型 def test_model_loads(self): """测试模型是否能成功加载""" self.assertIsNotNone(self.model) def test_basic_colorization(self): """测试基础的上色功能""" # 读取测试用的老照片 test_image_path = 'src/test_input.jpg' input_image = Image.open(test_image_path) # 运行上色 result_image = run_colorization(self.model, input_image) # 基础断言：确保有输出，且输出是图像 self.assertIsNotNone(result_image) self.assertEqual(result_image.mode, 'RGB') # 更高级的断言：可以计算输出图像与输入图像的某些差异 # 例如，上色后的图像整体不应该再是灰度图，颜色通道间应有差异 np_result = np.array(result_image) channel_std = np_result.std(axis=(0,1)) # 计算每个颜色通道的标准差 # 断言三个通道的标准差不会都接近于0（即不是灰度图） self.assertFalse(np.all(channel_std < 5)) if __name__ == '__main__': unittest.main()

写好这些测试，并确保它们在本地能够通过，我们就为自动化流水线准备好了“考题”。

4. 配置GitHub Actions CI流水线

GitHub Actions的配置文件放在.github/workflows/目录下。我们来创建一个ci-cd-pipeline.yml。

这个工作流会在每次向主分支（main）推送代码，或者发起拉取请求（PR）时触发。它分为两个主要的Job：test和build。

# .github/workflows/ci-cd-pipeline.yml name: DeOldify CI/CD Pipeline on: push: branches: [ main ] pull_request: branches: [ main ] jobs: test: runs-on: ubuntu-latest strategy: matrix: python-version: [‘3.8‘, ‘3.9‘] # 测试多个Python版本 steps: - name: Checkout code uses: actions/checkout@v3 - name: Set up Python ${{ matrix.python-version }} uses: actions/setup-python@v4 with: python-version: ${{ matrix.python-version }} - name: Install dependencies run: | python -m pip install --upgrade pip pip install -r requirements.txt pip install pytest # 安装测试框架 - name: Run unit tests (CPU) run: | python -m pytest tests/test_unit.py -v model-test: needs: test # 等待单元测试通过 runs-on: [self-hosted, gpu] # 关键：使用带有GPU标签的自托管Runner # 或者使用云厂商提供的GPU Runner，这里假设我们配置了指向星图GPU环境的自托管Runner steps: - name: Checkout code uses: actions/checkout@v3 - name: Set up Python uses: actions/setup-python@v4 with: python-version: ‘3.8‘ - name: Install dependencies with CUDA support run: | pip install torch torchvision --extra-index-url https://download.pytorch.org/whl/cu116 # 示例CUDA版本 pip install -r requirements.txt pip install pytest - name: Run model inference tests (GPU) run: | python -m pytest tests/test_model_inference.py -v env: # 可以设置一些环境变量，例如模型缓存路径 MODEL_CACHE_DIR: /tmp/models

配置解读：

testJob：在GitHub托管的Ubuntu虚拟机上运行，执行不依赖GPU的单元测试。我们使用矩阵策略来测试多个Python版本，确保兼容性。
model-testJob：这是关键。它needs: test，意味着只有单元测试通过后才会运行。runs-on: [self-hosted, gpu]指定了它需要在带有GPU的自托管Runner上执行。
- 如何获得GPU Runner？我们可以在星图GPU平台申请一台GPU实例，然后在这台实例上安装并注册GitHub Actions的自托管Runner软件，并为其打上gpu标签。这样，当这个Job被触发时，GitHub就会将任务调度到我们这台拥有GPU的机器上执行，从而完成模型推理测试。

通过这两个测试Job，我们确保了代码变更既不会破坏基础逻辑，也不会影响核心的模型上色功能。

5. 集成星图平台API实现自动构建

当所有测试都通过后，我们就可以进入构建和推送镜像的CD阶段了。我们将创建一个新的Job，叫做build-and-push。

这个Job的核心是调用星图GPU平台提供的镜像构建API。通常，这类API需要认证，我们可以将认证所需的令牌（Token）存储在GitHub仓库的Settings -> Secrets中。

# 接在 model-test job 之后 build-and-push: needs: model-test # 等待模型测试通过 runs-on: ubuntu-latest # 仅当推送到main分支时才构建镜像，PR时不构建 if: github.event_name == ‘push‘ && github.ref == ‘refs/heads/main‘ steps: - name: Checkout code uses: actions/checkout@v3 - name: Prepare build context run: | # 这里可以执行一些构建前的准备工作，比如生成版本号 echo “BUILD_VERSION=$(date +‘%Y%m%d‘)-${GITHUB_SHA:0:8}“ >> $GITHUB_ENV - name: Build and Push via Platform API env: PLATFORM_TOKEN: ${{ secrets.STARRY_API_TOKEN }} # 从GitHub Secrets读取平台API令牌 REGISTRY_URL: ‘your-registry.cn-beijing.cr.aliyuncs.com‘ # 星图平台镜像仓库地址示例 REPO_NAMESPACE: ‘your-namespace‘ REPO_NAME: ‘deoldify‘ run: | # 1. 调用平台API触发镜像构建 # 假设平台API端点为 /api/v2/build， 使用JSON传递参数 BUILD_DATA=$(cat <<EOF { “repoType“: “github“, “repoUrl“: “${{ github.server_url }}/${{ github.repository }}.git“, “branch“: “main“, “dockerfilePath“: “Dockerfile“, “imageTag“: “${REGISTRY_URL}/${REPO_NAMESPACE}/${REPO_NAME}:${BUILD_VERSION}“, “buildArgs“: { “COMMIT_SHA“: “${{ github.sha }}“ } } EOF ) echo “Triggering build via platform API...“ RESPONSE=$(curl -s -X POST \ -H “Authorization: Bearer ${PLATFORM_TOKEN}“ \ -H “Content-Type: application/json“ \ -d “$BUILD_DATA“ \ “https://api.your-platform.com/api/v2/build“) echo “API Response: $RESPONSE“ # 2. 解析响应，获取构建任务ID，并可选地轮询状态直到完成 BUILD_ID=$(echo $RESPONSE | jq -r ‘.data.buildId‘) if [ “$BUILD_ID“ != “null“ ]; then echo “Build task created with ID: $BUILD_ID“ # 这里可以添加一个循环，定期查询构建状态 # until [ “$STATUS“ = “SUCCESS“ ] || [ “$STATUS“ = “FAILED“ ]; do ... else echo “Failed to trigger build.“ exit 1 fi - name: Notify Success if: success() run: | echo “🎉 CI/CD Pipeline Succeeded!“ echo “New image tagged as: ${REGISTRY_URL}/${REPO_NAMESPACE}/${REPO_NAME}:${BUILD_VERSION}“ # 可以集成钉钉、飞书、Slack等Webhook通知团队

这个步骤的要点：

安全认证：平台的API令牌 (PLATFORM_TOKEN) 作为敏感信息，绝不以明文出现在代码中，而是通过GitHub Secrets管理。
构建触发：我们不再在GitHub Actions的Runner里执行docker build/push，而是向星图平台的API发送一个请求，告知平台：“请根据我这个Git仓库的main分支和这个Dockerfile，帮我构建一个镜像，并打上指定的标签，推送到我的私有仓库。”
优势：
- 无需管理构建服务器：平台负责提供构建环境。
- 网络优化：平台内网构建和推送镜像到同平台的仓库，速度极快。
- 资源隔离：构建过程消耗的资源由平台管理，不影响你的GitHub Actions配额。

6. 实践中的技巧与避坑指南

这套流程搭起来后，在实际运行中我积累了一些经验，也踩过一些坑，分享给你可能用得上。

1. 测试数据的处理模型测试需要输入图片。千万不要把大的测试数据集（尤其是原始训练数据）放进代码仓库。推荐做法：

将小的、有代表性的样例图片（如test_input.jpg）放在仓库内。
如果需要更大的测试集，可以将其放在云存储（如OSS）上，在测试开始时通过脚本下载。记得在GitHub Secrets中配置云存储的访问密钥。

2. 依赖管理与缓存Python依赖安装，特别是torch这种大家伙，很耗时。可以利用GitHub Actions的缓存功能加速。

- name: Cache pip packages uses: actions/cache@v3 with: path: ~/.cache/pip key: ${{ runner.os }}-pip-${{ hashFiles(‘requirements.txt‘) }} restore-keys: | ${{ runner.os }}-pip-

3. 镜像版本标签策略好的标签策略让你一眼就知道镜像的来历。我常用的格式是：

{日期}-{commit短SHA}: 如20231027-abc123f，对应一次具体的提交。
latest: 始终指向main分支最新成功构建的镜像（谨慎使用）。
v1.0.0: 对应正式的发布版本。

在API触发构建时，可以将这些标签组合推送。

4. 处理GPU Runner的稳定性自托管的GPU Runner可能因为网络、资源竞争等问题不稳定。建议：

为Runner设置监控，确保其在线。
在model-testJob中增加错误重试逻辑。
考虑使用平台托管的、按需发起的GPU测试环境，而非长期运行的Runner，这通常更稳定且成本可控。

5. 流水线状态通知除了在GitHub页面上查看，还可以将成功或失败的结果通知到团队聊天工具。这能极大提升协作效率。

7. 总结

回过头来看，把DeOldify和GitHub CI/CD流水线结合，最大的感受就是“省心”。以前提代码像走钢丝，现在提交完就能放心去做别的事，失败了有即时通知，成功了就有现成的镜像等着部署。

这套方案的核心思路其实不限于DeOldify，任何涉及AI模型开发、需要GPU测试的项目都可以借鉴。关键是把那些重复、易错的手工操作，变成一套定义清晰、自动执行的规则。GitHub Actions负责编排和CPU测试，星图这类GPU平台提供强大的算力和便捷的镜像服务，两者一结合，就形成了从代码到服务的自动化高速公路。

刚开始搭建可能会觉得有点繁琐，但一旦跑通，它带来的效率提升和团队协作的顺畅感，绝对是值得的。如果你也在做类似的项目，不妨从为一个核心函数写一个自动化测试开始，一步步地把这个流水线搭建起来。