第21章持续集成与自动化

课程目录第21章持续集成与自动化

21、持续集成与自动化：CI/CD流水线搭建、自动化测试集成、代码质量门禁

说实话，很多C语言项目团队，代码写得挺漂亮，但一说到「自动化构建」就皱眉头。我见过太多团队还在用手动编译、人工跑测试、靠邮件通知bug的方式干活。嗯，这在十年前或许还能忍，但现在项目动辄几十万行代码，再这么搞，迟早要出大事。

持续集成（CI）说白了就是：每次代码提交，自动触发构建、测试、静态分析。你只管写代码，剩下的脏活累活交给流水线。我个人习惯是，哪怕一个只有三个人的小项目，也要搭一套CI。为什么？因为省下来的时间，够你多喝好几杯咖啡。

  核心目标：让每一次提交都经过「编译→单元测试→静态分析→集成测试」的完整检验，不合格的代码根本进不了主干。

CI/CD流水线的基本架构

先看一张我画的流程图，帮你快速理解整个流水线的运转逻辑：

这张图看起来简单，但每个环节都有不少坑。我一个个拆开来讲。

流水线搭建：从零开始

选CI工具，我个人比较推荐 Jenkins 或 GitLab CI。如果你团队小，GitLab CI 开箱即用，省心。Jenkins 虽然配置复杂，但插件生态丰富，适合大型项目。

下面是一个典型的 .gitlab-ci.yml 配置片段，针对C语言项目：

stages:
  - build
  - test
  - static_analysis
  - deploy

build_job:
  stage: build
  script:
    - mkdir -p build
    - cd build
    - cmake ..
    - make -j$(nproc)
  artifacts:
    paths:
      - build/
    expire_in: 1 hour

test_job:
  stage: test
  script:
    - cd build
    - ctest --output-on-failure
  dependencies:
    - build_job

static_analysis_job:
  stage: static_analysis
  script:
    - cppcheck --enable=all --suppress=missingIncludeSystem .
    - sonar-scanner
  only:
    - master

小提示：artifacts 的过期时间别设太长。我见过有人设成「never」，结果服务器硬盘被撑爆了。1小时足够调试用了。

自动化测试集成：别让测试成为摆设

很多C语言项目，测试代码写得比业务代码还复杂，但跑一次要半小时。你想想看，谁会愿意每次提交都等半小时？

我的建议是：分层测试。

单元测试：针对函数级别，跑得飞快。用 CUnit 或 Unity 框架，几百个用例也就几秒钟。
集成测试：针对模块间交互，可以慢一点，但别超过5分钟。
系统测试：全量回归，可以放到夜间跑。

我曾经在一个嵌入式项目中，把单元测试从30分钟优化到2分钟。怎么做的？说白了就是去掉那些不必要的硬件依赖，用 mock 替代真实驱动。代码示例如下：

// 原始测试：依赖真实硬件
void test_sensor_read(void) {
    int val = sensor_read();  // 需要硬件在线
    CU_ASSERT(val > 0);
}

// 优化后：使用 mock
void test_sensor_read_mock(void) {
    mock_sensor_set_value(42);
    int val = sensor_read();  // 从 mock 读取
    CU_ASSERT_EQUAL(val, 42);
}

注意：mock 不是万能的。过度 mock 会导致测试脱离实际。我见过一个项目，所有测试都用了 mock，结果集成时发现接口对不上，全白测了。

代码质量门禁：把坏代码挡在门外

质量门禁，说白了就是一道「安检」。代码想合入主干？先过我这关。

常用的门禁指标包括：

指标	阈值（建议）	工具
代码行覆盖率	≥ 80%	gcov + lcov
分支覆盖率	≥ 70%	gcov + lcov
静态分析告警数	0 严重告警	Cppcheck / Coverity
圈复杂度	≤ 15	SonarQube
重复代码比例	≤ 5%	SonarQube / PMD

嗯，这里要注意：门禁不是越严越好。我曾经在一个项目里把覆盖率门槛设到90%，结果团队怨声载道，为了凑覆盖率写了很多「假测试」。后来我降到80%，配合代码审查，效果反而更好。

  我的经验：门禁的阈值要「动态调整」。新项目可以宽松点（比如覆盖率60%），等代码稳定了再逐步收紧。别一上来就搞「一刀切」。

避坑指南：我踩过的那些坑

做CI/CD这么多年，踩过的坑能写一本书。挑几个典型的说说：

编译环境不一致：开发机是Ubuntu 20.04，CI服务器是CentOS 7，结果链接器版本不同，编译通过但运行崩溃。解决方案：用Docker统一环境。
测试数据污染：多个流水线并行跑，共用同一个数据库，测试数据互相干扰。解决方案：每个流水线用独立的测试数据库，跑完自动清理。
门禁误报太多：静态分析工具报了一堆告警，但大部分是误报。团队开始「无视告警」，门禁形同虚设。解决方案：定制规则集，过滤掉已知的误报模式。

我曾经遇到一个最离谱的坑：CI流水线跑了2小时，最后一步部署时发现磁盘空间不足。原因是构建产物没清理，日积月累把硬盘塞满了。从那以后，我每个流水线第一步都是 df -h 检查磁盘。

总结一下

CI/CD流水线不是「搭完就完事」的东西。它需要持续维护、持续优化。我个人习惯是每季度 review 一次流水线配置，看看有没有可以提速的地方，有没有新的工具可以集成。

记住一句话：流水线是团队的「护城河」。它保护的不只是代码质量，更是团队的交付信心。当你能放心地「一键部署」时，你就知道，这功夫没白花。

最后一个小建议：从最简单的开始。先保证「编译通过 + 单元测试通过」，再逐步加入静态分析、覆盖率、集成测试。别想一口吃成胖子。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

21、持续集成与自动化：CI/CD流水线搭建、自动化测试集成、代码质量门禁

CI/CD流水线的基本架构

流水线搭建：从零开始

自动化测试集成：别让测试成为摆设

代码质量门禁：把坏代码挡在门外

避坑指南：我踩过的那些坑

总结一下