CI/CD (Continuous Integration / Continuous Deployment)

CI/CD (Continuous Integration / Continuous Deployment) – definition

CI/CD is a software delivery practice that automates the integration, verification, packaging, and release of software changes. Continuous Integration (CI) means that developers merge changes into a shared codebase frequently and validate them through automated builds and tests. Continuous Delivery (CD) extends this process by automatically preparing validated artifacts for release, while Continuous Deployment automatically releases validated changes to a target environment.

In mobile robotics, CI/CD applies to ROS 2 packages, robot firmware, container images, configuration files, simulation worlds, and deployment scripts. Its purpose is to detect integration failures before software reaches a physical unmanned ground vehicle (UGV). A CI pipeline can verify that a ROS 2 workspace builds, unit tests pass, interfaces remain compatible, and a navigation stack starts in simulation. A CD pipeline can publish a versioned Docker image or install a tested software release on a Leo Rover or Raph Rover.

CI/CD does not make a UGV autonomous by itself. It provides a controlled process for delivering software such as SLAM, navigation, sensor drivers, perception nodes, and robot-specific configuration.

CI and CD in a ROS 2 workspace

A ROS 2 application is commonly organised as an ament workspace containing one or more packages. Each package declares build, execution, and test dependencies in package.xml. The standard ROS 2 build tool is colcon, which builds packages in dependency order and can execute registered tests.

A typical CI job for a ROS 2 UGV project performs the following checks on every pull request or merge request:

Checks out a pinned source revision.
Installs dependencies with rosdep.
Builds the workspace with colcon build.
Runs package tests with colcon test.
Processes test results with colcon test-result.
Runs static analysis, formatting, and lint checks where configured.
Optionally launches simulation and integration tests.

ROS 2 packages can register tests through ament_cmake or ament_python. Common ROS 2 test mechanisms include ament_lint_auto, ament_cmake_gtest, pytest, and launch testing. Launch tests are important for robotics because they can verify that nodes start, required topics appear, parameters load, and expected messages are published.

source /opt/ros/humble/setup.bash
rosdep update
rosdep install --from-paths src --ignore-src -r -y
colcon build --event-handlers console_direct+
colcon test --event-handlers console_direct+
colcon test-result --verbose

The example uses ROS 2 Humble. Leo Rover projects may use ROS 2 Humble or a later distribution when it is supported by the selected Leo Rover software image and hardware configuration, but projects should build against the exact ROS distribution deployed on the robot. ROS 2 distributions have different supported platforms, dependency versions, and API availability. ROS distribution release status is defined by ROS Enhancement Proposal REP 2000.

CI/CD pipeline stages for mobile robots

A robotics pipeline should separate checks that are safe and deterministic in CI from checks that require physical hardware. Unit tests and container builds are suitable for hosted runners. Sensor validation, motor safety checks, and wireless-network tests normally require a controlled hardware-in-the-loop environment.

Stage	Typical ROS 2 artifact	Validation objective
Build	ROS 2 workspace	Compile C++ nodes and resolve declared dependencies.
Unit test	Libraries and algorithms	Verify deterministic functions, coordinate conversions, parsers, and safety limits.
Interface test	Messages, services, actions	Confirm expected ROS graph names, types, and parameter interfaces.
Simulation test	URDF, launch files, Nav2 configuration	Verify startup and nominal behaviour without moving a physical UGV.
Package	Docker image or Debian package	Create an immutable, versioned deployment artifact.
Deployment	Robot compute unit	Install an approved artifact and retain a rollback path.

Docker-based deployment for Leo Rover and Raph Rover

Container images reduce differences between a developer workstation, CI runner, and robot computer. A Docker image can include a specific Ubuntu base image, ROS 2 distribution, system dependencies, ROS packages, and launch files. The image tag should identify an immutable source revision, such as a Git commit SHA, rather than only a mutable tag such as latest.

Leo Rover uses a built-in Raspberry Pi compute unit by default. Build artifacts for this platform must match the target CPU architecture, typically ARM64 when the robot uses a 64-bit Raspberry Pi operating system installation. A pipeline running on an x86-64 server can use a native ARM64 runner or multi-architecture build tooling. The resulting image must be tested on the actual target architecture because binary dependencies and hardware access can differ.

Raph Rover can carry a larger payload and may use a different onboard computer configuration. Its deployment pipeline should therefore treat the robot configuration as an explicit target. This includes architecture, operating system, ROS distribution, sensor set, network settings, and motor-controller interface.

name: ros2-ci

on:
  pull_request:
  push:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-22.04
    container: ros:humble-ros-base
    steps:
      - uses: actions/checkout@v4
      - name: Install dependencies
        run: |
          apt-get update
          apt-get install -y build-essential python3-colcon-common-extensions python3-rosdep
          rosdep init || true
          rosdep update
          rosdep install --from-paths src --ignore-src -r -y
      - name: Build
        run: |
          . /opt/ros/humble/setup.sh
          colcon build
      - name: Test
        run: |
          . /opt/ros/humble/setup.sh
          colcon test
          colcon test-result --verbose

Key CI/CD metrics and acceptance criteria

Metrics make CI/CD performance measurable. They should be interpreted together with test scope. A short pipeline is not useful if it omits interface or integration failures that can affect UGV operation.

Build success rate: percentage of pipeline runs completing the build stage successfully.
Test pass rate: percentage of executed test cases that pass for a defined revision.
Pipeline duration: elapsed time from job start to final result. This affects developer feedback latency.
Deployment frequency: number of approved releases delivered to a test or production robot environment within a defined period.
Mean time to restore: time required to return a robot to a known working software version after a failed deployment.
Artifact traceability: ability to map a running image, package, or firmware file to a source commit, build log, dependency set, and configuration revision.

For navigation and perception software, acceptance criteria should also include robot-specific checks. Examples include successful TF tree creation, valid odometry publication, availability of required sensor topics, and loading of parameter files. The required message types may include nav_msgs/msg/Odometry, sensor_msgs/msg/Imu, sensor_msgs/msg/LaserScan, and sensor_msgs/msg/Image.

Safety and limitations

CI tests cannot prove that a mobile robot is safe in every physical environment. Simulation does not fully reproduce wheel slip, lighting variation, LiDAR reflections, GPS multipath, battery voltage changes, radio dropouts, or payload-dependent dynamics. A successful pipeline is evidence that defined checks passed, not a guarantee of operational safety.

For Leo Rover, the differential-drive base, four-wheel configuration, and IP55 enclosure do not remove the need for deployment controls. Before testing autonomous navigation, operators should validate emergency stop procedures, motor-control behaviour, velocity limits, sensor mounting, and the local operating area. The same principle applies to Raph Rover, particularly when its larger payload capability changes mass distribution or braking distance.

A practical CD process uses staged environments. A release is first validated in simulation, then on a supervised development robot, and only then promoted to a broader fleet or field test. Rollback should use a previously tested versioned artifact and configuration set.

Normative references and technical sources

The following primary documentation defines the relevant ROS 2 build, release, and interface mechanisms:

ROS 2 testing documentation – ROS 2 Humble documentation.
colcon documentation – build and test execution for ROS workspaces.
REP 149 – ROS package manifest format.
REP 2000 – ROS distribution releases and target platforms.
Leo Rover technical documentation – Fictionlab platform documentation.

CI/CD (Continuous Integration / Continuous Deployment)