Definition
CI/CD (Continuous Integration / Continuous Deployment) refers to continuous integration and continuous deployment, completing code building, testing, signing, and release through an automated pipeline. The Device Management Platform can integrate firmware building and OTA release into CI/CD, enabling rapid version iteration, combined with Changelog automatic generation.
Pipeline Stages
A typical CI/CD pipeline includes: code commit triggers, compilation/building, unit and integration testing, static analysis and security scanning, firmware signing (Firmware Signature), packaging and version tagging, uploading to OTA services, and optional phased release. The Device Management Platform provides APIs or Webhooks for tools like Jenkins, GitLab CI, GitHub Actions to call, achieving an automated loop of "commit triggers build, build triggers release."
Application in Device Management
The firmware development team can automatically upload build artifacts to the platform's OTA module via CI/CD, reducing manual upload errors; it can be configured to automatically create phased release tasks, generate Changelog, and notify relevant parties. On the platform side, version verification and signature validation are supported to ensure that only firmware verified through the pipeline can be deployed, enhancing OTA security and release efficiency.
Best Practices
It is recommended to bind the firmware version number with Git Tag or build number to facilitate traceability; add device simulation testing or real machine smoke testing to the pipeline; use manual approval or staged grayscale for production release to avoid the risk of full push.
How far a pipeline may run on its own
In device management, continuous integration and continuous delivery mean using one repeatable sequence of steps to turn source into firmware that can be signed, and to register it in the release library. It does not mean that every commit is written at once into every device in service. The automatic part usually stops at compile, test, sign, generate the version note, and upload into the candidate area of a named product. From the candidate area to a field job, a person still confirms the applicable hardware version, the source-version range, and the push batch. A pipeline means something only when the build environment, the signing key, and the product identifier are fixed. If the key lives on a developer’s laptop, another machine is no longer the same pipeline.
What belongs in the pipeline is firmware that already has a stable artifact format and a version-number rule. An early version that is still changing partition layout or protocol often can be compiled and tested automatically, but it should not enter a directory that may be delivered to the field on its own. Each build should leave the source revision, the dependency versions, and the signing result, so a version on a device can be matched later. An image related to an A/B partition should also be checked in the pipeline for whether it fits the slot size, so a package is not shown as releasable in the cloud and then fails to write into the idle slot on the device.
When an unsigned package enters the release channel
A likely mistake is to treat a passed test as permission to skip signing. After a test environment turns verification off to go faster, the same pipeline copied to production lets an unsigned package, or a package signed with the test key, into the release list. Another mistake is a changed build number with an unchanged version number. The device treats “already latest” by version number and refuses, or installs different content under the same number twice. Marking a failed step as ignorable also uploads after signing or packaging has failed, and a partial package appears on the platform.
A human release that looks only at a green pipeline, and not at the hardware the artifact is for, pushes a package verified only on a new board to an old board. The canary share and the observation time should not be written into a script that nobody can change. The result of the first batch of a gray release should return to the pipeline record and decide whether the next batch is allowed, rather than the end of the build defaulting to everyone. When keys are rotated, old packages must still verify with the old public key, and new packages must use the new key. The two chains coexist during the transition. Verification material must not all be invalidated in a single day.
The boundary between a candidate package and a field job
A pipeline putting a package into the release library only means the artifact can be selected. It does not mean it has permission to be delivered to a particular set of field devices. Between the candidate area and an executable job there should be one explicit release: check the hardware revision, the applicable source version, the key used to sign, and whether the change note matches this package. The person releasing must be able to see whether a failed test was ignored or really passed. Making creation of a production job happen automatically on commit means every merge might reach the field. Automatic install onto a test group can remain. Its target should be a fixed set of trial devices, and it must not share a trigger with the dynamic scope of a customer site.
The build environment itself has to be repeatable. Floating dependency versions, a wrong clock on the signing machine, or a script that keeps uploading after a failure all produce a candidate that is green and not trustworthy. The artifact should carry the source revision, the build number, and a hash. The version a field device reports must be able to return to one of those. With only a version number and no build number, two packages of different content look like the same entry in the list. During key rotation, an old candidate and a new candidate must be described with their own verification material. They must not be collapsed in the release record into “signed.” Once the boundary is clear, the pipeline shortens preparation. Field risk is still controlled by the release and by the batches.