18 CI/CD Fundamentals for IoT

Continuous Integration, Continuous Delivery, Pipelines, and Release Gates

testing

validation

cicd

iot

Keywords

CI/CD for IoT, continuous integration, continuous delivery, build pipeline, automated quality gate, firmware artifact, build matrix, artifact promotion, release gate

Start With the Change That Must Ship

Imagine changing one line of firmware for a sensor device and then being asked a practical question: can this exact change go to real hardware? A CI/CD pipeline is the evidence trail that answers. It links the source change to the build, the tests, the signed artifact, the release gate, and the retest trigger, so a reviewer can approve or hold the candidate without guessing which bytes are about to ship.

Overview: From a Change to a Releasable Candidate, Repeatably

Continuous integration and continuous delivery describe one disciplined path: every change to firmware, configuration, or service code is built and tested automatically, and the result is a candidate that is always ready to release behind a deliberate gate. Continuous integration is the front half — integrate small changes frequently so a machine builds and tests each one, catching conflicts and regressions while they are small. Continuous delivery is the back half — keep a tested candidate that can be approved, paused, rolled out in stages, or rolled back at any time.

The value is not "automatic release." The value is repeatable evidence and fast feedback: a record of what changed, what was built, which checks ran, what passed or failed, and which artifact is allowed to ship. IoT raises the bar over a web pipeline because the same source may have to build for several hardware targets, the output is a firmware image with a manifest and a signature rather than a container, real-device timing matters, and you cannot quietly hotfix a device in someone's wall. The pipeline has to make those hardware-shaped assumptions visible instead of hiding them behind a single green check.

If you only need the intuition, this layer is enough: continuous integration builds and tests every change automatically; continuous delivery keeps a releasable, gated candidate ready at all times. The pipeline's job is repeatable evidence and fast feedback, and for IoT that evidence must include the hardware targets, the signed artifact, and the recovery plan, not just "the build passed."

The pipeline is an evidence path: each stage leaves a record that traces back to the change and forward to the release decision.

The One-Minute View

Integrate continuously

Every change is built and tested automatically so conflicts and regressions surface while they are small.

Gate before release

Continuous delivery keeps a tested candidate ready, released only through a deliberate gate.

Hardware changes the bar

Multiple build targets, signed firmware artifacts, and no easy field hotfix make IoT pipelines carry extra evidence.

Beginner Examples

A developer pushes a one-line firmware fix; the pipeline rebuilds for every supported board and runs the test suite before anyone reviews it.
A build is green, but the release gate holds it because the security scan has not run — "all jobs passed" is not "approved to ship."
The artifact engineers tested and the artifact that reaches devices are the same signed image, tied together by a digest, not rebuilt at deploy time.

Overview Knowledge Check

If you can separate continuous integration from continuous delivery, you have the core idea. Continue to Practitioner for the pipeline stages and the gates that protect a release.

Practitioner: Pipeline Stages and Automated Gates

A pipeline is a sequence of stages, each triggered by the last and each leaving evidence. A typical IoT flow runs: a commit triggers the pipeline; the candidate is built (often cross-compiled for several hardware targets); static analysis and unit tests run close to the change; integration and hardware-aware tests exercise the boundaries the change can affect; the artifact is packaged, versioned, and signed; a release gate compares the evidence against the change; and delivery proceeds in stages to the fleet. The sequence keeps fast checks early, so most failures stop the pipeline in seconds, and slow real-device checks later, where they are worth their cost.

Automated Quality Gates

Between stages sit automated gates: conditions the candidate must meet to proceed. The build must succeed for every claimed target; unit and static checks must pass; a security scan must run; lint or coverage thresholds, where the team sets them, must hold. A failed gate stops the pipeline and reports why, which is the mechanism that keeps a broken change from advancing. A gate is only honest if a skipped check is recorded as skipped with a reason and owner, never silently passed.

The release gate compares evidence against the change and produces a decision: approve, hold, roll back, or retest.

Cadence: Run the Right Stage at the Right Time

Not every stage runs on every change. Keep developer feedback in seconds by running the build, static analysis, and unit tests on every commit; run integration and security scans on pull requests; run hardware-in-the-loop and extended integration nightly; and reserve full regression and the release gate for the candidate being prepared to ship. This is the testing pyramid's cadence applied to delivery: fast checks gate every change, expensive checks run when they are worth it.

Stage

What It Proves

Evidence to Keep

Failure Mode If Weak

Change record

The candidate ties to a reviewed change with an expected result.

Affected behavior, target boundary, and retest trigger.

Later stages pass while checking the wrong thing.

Build (per target)

The candidate compiles for every hardware target it claims.

Source revision, target, build config, artifact name, and digest.

A change builds for one board and silently breaks another.

Static + unit

The changed code path behaves in isolation.

Analyzer findings and unit results for the change.

Early defects slip to slower, costlier stages.

Integration + HIL

The affected interfaces and real-device timing hold.

Which boundary was covered and which remains open.

Interface and timing bugs reach the field.

Package + sign

The shippable artifact is identified and authorized.

Version, manifest, digest, and signature reference.

The wrong or unverified image can ship.

Release gate

The evidence matches the change before delivery.

Approve, hold, roll back, or retest with a reason.

A green pipeline is mistaken for an approved release.

Practitioner Knowledge Check

If you can place the stages, set the gates, and run them at the right cadence, you can stop here. Continue to Under the Hood for the parts of IoT delivery a web pipeline never has to handle.

Under the Hood: What Makes an IoT Pipeline Different

The deeper layer is the handful of mechanisms that separate an IoT pipeline from an ordinary software one: building for many targets, keeping the tested artifact identical to the shipped artifact, putting real hardware in the loop, and ending every candidate with a recovery decision.

Cross-Compilation and the Build Matrix

A single firmware change often must build for several boards, chips, or sensor configurations, each with its own toolchain and constraints. A build matrix compiles the candidate for every claimed target, so a change that passes on one and fails on another is caught in CI, not in the field. The build evidence must name the target and configuration, because "it built" is meaningless without saying for what.

The Tested Artifact Must Be the Shipped Artifact

A web service can often be rebuilt at deploy time with little consequence. A firmware candidate must not be. The image engineers tested, the image the gate approved, and the image devices receive have to be the same bytes — promoted, not rebuilt — tied together by a digest and a signature. Rebuilding after testing reintroduces the risk the tests were meant to remove, because the shipped image was never the one under test. This is also why the artifact's manifest and signature belong in the pipeline's evidence.

Real Hardware in the Loop

Some defects only appear with real timing, interrupts, and I/O. Bringing hardware-in-the-loop rigs or device farms into the pipeline lets the slow, real-device tests run on a schedule against the actual target, surfacing race conditions and timing faults that deterministic host-based unit tests never trigger. An intermittent failure on such a rig is usually a real bug, not a flaky job to rerun until it is green.

Every Candidate Ends with a Recovery Decision

Because a bad firmware release can brick devices you cannot reach, the gate's output is not just approve or reject. For any change that can affect boot, update, or recovery state, the record must name the rollback or recovery path and the retest trigger before the candidate moves on. Delivery itself should be staged — a small cohort first, expanding only while telemetry stays clean — so a bad release reaches few devices; the mechanics of staged rollout and rollback are covered in the linked chapters.

Common Review Findings

Green pipeline treated as proof. The gate must compare evidence to the change, not just collect passes.
Tested and approved artifact not tied together. Without a shared digest, the shipped image may never have been tested.
Skipped checks hidden in logs. A skip belongs in the record with a reason and owner.
Flaky boundary rerun to green. Rerunning a hardware-aware check until it passes hides a real, uncertain boundary instead of resolving it.
No recovery decision. A candidate that can affect update or boot state is approved with no rollback or recovery recorded.
No retest trigger. The same candidate cannot be reliably re-evaluated after a related change.

Under-the-Hood Knowledge Check

At this depth, IoT CI/CD is a discipline of traceable, hardware-aware evidence: build for every target, keep the tested artifact identical to the shipped one, put real hardware in the loop, and end each candidate with a recovery decision. A trustworthy pipeline answers which stage produced each result and proves the image that ships is the image that passed.

18.1 Summary

Continuous integration builds and tests every change automatically; continuous delivery keeps a tested, gated candidate ready to release. The value is repeatable evidence and fast feedback, not automatic release.
IoT pipelines carry more than a web pipeline: multiple hardware build targets, signed firmware artifacts with manifests, real-device timing, and no easy field hotfix.
A typical pipeline runs commit → build (per target) → static + unit → integration + hardware-aware → package + sign → release gate → staged delivery, each stage leaving evidence.
Automated quality gates stop a candidate that fails a required check; a gate is honest only when a skipped check is recorded with a reason and owner.
Run fast checks on every commit and reserve slow, real-device checks for nightly or release cadence, applying the pyramid’s cadence to delivery.
A build matrix compiles for every claimed target; the tested, approved, and shipped artifact must be the same bytes, promoted and verified by digest rather than rebuilt.
Hardware-in-the-loop in CI surfaces timing bugs; every candidate that can affect boot, update, or recovery must record a rollback path and retest trigger, with delivery staged to bound the blast radius.

Key Takeaway

An IoT CI/CD pipeline earns trust by making hardware-shaped evidence visible: it builds for every target, proves the shipped image is the tested image, runs real hardware in the loop, and never approves a firmware candidate without a recovery path. Ask of any release: which stage produced this decision, and is the image about to ship the exact one that passed the gate?