上篇聊了clang-tidy、cppcheck这些代码质量工具最后提到要把它们串进CI流水线。今天就把CI/CD这件事展开讲透。面试的时候被问你们代码提交之后怎么保证编译通过、测试能跑我当时说本地跑一遍没问题就push。面试官又问那多人协作呢每个人本地都跑一遍我想了想好像确实不太对。这就是CI/CD要解决的问题。CI是持续集成Continuous IntegrationCD是持续交付Continuous Delivery或者持续部署Continuous Deployment。说白了就是代码一提交自动跑编译、跑测试、跑代码检查全过了才算合格。不用人盯着机器帮你把关。在机器人项目里CI/CD特别重要。因为机器人软件依赖复杂ROS2、各种第三方库、编译时间长、测试需要仿真环境如果没有自动化流程光靠人工检查根本管不过来。GitHub Actions轻量级CI首选GitHub Actions是目前最流行的CI方案之一。配置简单和GitHub仓库深度集成开源项目免费用。在项目根目录创建.github/workflows/ci.ymlname: CI on: [push, pull_request] jobs: build-and-test: runs-on: ubuntu-22.04 container: ros:humble steps: - uses: actions/checkoutv4 - name: Install dependencies run: | apt-get update rosdep update rosdep install --from-paths src --ignore-src -y - name: Build run: | source /opt/ros/humble/setup.bash colcon build --cmake-args -DCMAKE_BUILD_TYPERelease - name: Run tests run: | source /opt/ros/humble/setup.bash source install/setup.bash colcon test colcon test-result --verbose每次push或者创建PRGitHub自动启动一个Ubuntu容器装好ROS2 Humble编译你的项目跑测试。编译失败或者测试不通过PR上会显示红叉reviewer一看就知道。GitHub Actions的优势在于配置简单、生态丰富。社区有大量现成的Action可以复用比如checkout代码、缓存编译产物、上传测试报告等。说说实际用的几个技巧。Matrix策略同时测试多个ROS2版本和Ubuntu版本。比如你的项目要支持Humble和Iron两个LTS版本可以配成matrixstrategy: matrix: ros_distro: [humble, iron] ubuntu: [22.04, 24.04]这样每次提交会同时跑4个job确保代码在所有目标环境上都能编译通过。缓存加速ROS项目编译一次可能要10-20分钟每次都从头编译太慢了。用ccache可以缓存编译结果第二次编译只编译改动过的文件。配置大概是这样- uses: hendrikmuhs/ccache-actionv1.2 with: key: ${{ matrix.ros_distro }}加上缓存以后增量编译通常只要1-2分钟。这个优化对开发体验的提升是巨大的——你提一个PR等2分钟就知道结果和等20分钟完全是两种心态。Artifact上传编译产物可以上传为GitHub Artifact方便下载和部署。测试报告也可以上传在PR页面上直接看到哪些测试通过了、哪些失败了。机器人项目中的CI实践机器人项目的CI比纯软件项目复杂主要因为几点。依赖管理ROS2项目依赖大量系统包CI环境需要预装。常见做法是用Docker镜像把ROS2和常用依赖都装好。仿真测试很多测试需要Gazebo仿真环境。CI里可以用gz sim -s跑无渲染模式或用xvfb模拟显示。测试分层很重要。单元测试Google Test、pytest每次提交都跑几十秒出结果。集成测试Gazebo仿真在PR合并前跑一次。系统测试在真实硬件上跑每天定时一次。硬件在环测试由测试工程师手动执行。编译缓存用ccache缓存编译结果增量编译只要1-2分钟比从零编译快好几倍。一个实际的CI流水线说一个我参与搭建的CI流程供参考。代码push到feature分支后GitHub Actions自动触发clang-format检查代码格式、clang-tidy静态分析、编译用ccache加速、跑单元测试。全部通过大概3-5分钟。创建PR时额外触发集成测试在Docker容器里启动Gazebo无头模式跑几个预定义的测试场景。通过后才允许合并。合并到main分支后Jenkins接手交叉编译ARM版本、打包成deb包、推送到内部制品仓库。同时通知运维团队由他们决定什么时候部署到现场机器人上。这套流程跑了一年多整体还不错。唯一的问题是Gazebo集成测试偶尔会超时——仿真环境启动太慢。后来我们把测试场景简化了从5分钟缩短到2分钟超时问题基本解决了。CD从代码到机器人CI解决了代码对不对的问题CD解决怎么把代码部署到机器人上的问题。最简单的CDCI编译测试通过后自动把可执行文件scp到机器人上。正式的CD流程会更规范编译→测试→打包Docker镜像或deb包→推送到制品仓库→机器人拉取更新。在机器人产品中OTAOver-The-Air更新是标配。关键要求是原子更新——更新要么完全成功要么完全回滚。常见做法是A/B分区当前运行在A分区新版本写到B分区写完后切换启动分区。启动失败则自动切回。面试中怎么聊CI/CD面试官问CI/CD你可以说我们用GitHub Actions做CI每次PR自动在Docker容器里编译和测试。容器镜像预装了ROS2 Humble和常用依赖。编译用了ccache加速测试包括单元测试和集成测试。通过后自动打包成Docker镜像部署时用docker-compose在机器人上启动。这种回答好在有具体工具、有完整流程、有机器人特色。CI/CD在机器人项目中的实践机器人项目的CI/CD有个特殊挑战编译时间长。一个完整的ROS2 workspace编译可能需要十几分钟。优化策略包括用ccache缓存编译结果、用Docker镜像预装依赖、只编译改动的包。另外单元测试在CI中很重要可以用colcon test运行所有包的测试。一个实用的pipeline是代码提交、lint检查、编译、单元测试、打包Docker镜像、部署到测试机器人。补充一点在CI中运行ROS2测试时可以用launch_pytest框架来编写集成测试验证多个节点之间的交互是否正确。给你的建议如果你还没用过CI从GitHub Actions开始。创建一个仓库写一个最简单的workflowcheckout代码、编译、跑测试。第一次看到绿色的对勾出现在PR上你会觉得特别有成就感。机器人项目的CI可以从简单开始先保证每次提交能编译通过再逐步加测试、加代码检查、加部署。不要一上来就搞复杂的流水线团队维护不过来。最后CI的价值不只是自动化是信任。有了CI团队成员可以放心提交代码因为机器会帮你检查。code review也能更专注在逻辑和架构上不用操心编译能不能过。上一篇第104篇 代码质量工具——clang-tidy/cppcheck和机器人代码规范下一篇预告第106篇 ROS的前世今生——从ROS1到ROS2的进化逻辑有任何问题欢迎评论区留言我会尽量回复。