Definition
Gray Release refers to pushing a new version to a portion of devices during an OTA upgrade first, verifying stability before releasing fully, thereby reducing upgrade risks. Gray devices can be selected based on Device Grouping or proportions.
Gray Strategy
Common strategies include: selecting pilot devices by device grouping (Static Group or Dynamic Group); randomly selecting by proportion (e.g., 5%, 10%, 50% in batches); targeting by region, model, batch, and other dimensions. The platform supports multi-stage gray releases: the first stage involves small-scale verification to monitor success rate and alerts; after passing, expand the scope, and finally release fully.
Monitoring and Rollback
During the gray release, it is necessary to monitor upgrade success rate, device online rate, fault alerts, and other indicators. If gray devices encounter anomalies (such as mass offline or increased failure rate), the push can be immediately paused and Rollback triggered to restore upgraded devices to the previous version. The platform should support operations for pausing, resuming, and expanding gray tasks to achieve controlled progressive releases.
Best Practices
It is recommended to start with internal test devices or low-risk groups for gray release; set a gray observation period (e.g., 24–72 hours); define clear gray pass criteria (success rate thresholds, no severe alerts, etc.); and combine with Changelog for evaluating upgrade impacts and decision-making.
Staged verification versus one full push
A gray release splits one version change into steps that can be stopped. A small set of devices runs the new version first. Watch whether they still stay connected, finish the work that matters, and report as expected, and only then decide whether to widen. It is not finished by shuffling the device list at random, and it is not another name for "ship to the test environment first." Devices in a test environment often have stable power and a network that someone guarantees. A gray release has to face the kind of field device that is about to receive the full rollout. Each batch needs a clear condition for entering and a clear condition for stopping, for example no new widespread offline period during the watch, and no boot failure particular to this version. Batches should not write the same partition on top of each other, or the earlier batch is still confirming while the later one has already overwritten it. The task record should be able to say which devices are in the current batch, which version they came from, and which step they are on. Firmware update over the air is the act of changing the image. The gray release is the latch that decides when that act is allowed to grow.
What to observe before the next batch opens
Before the next batch opens, the previous one should already have passed the reboot and completed at least one report the service needs, not merely shown that the download progress ended. The watch window has to cover the device's real working cycle. Declaring success in the daytime for a device that communicates only at night is the same as not watching. The sample should include the hardware revisions, network types, and power arrangements this full rollout will meet. A lab bench, or a single customer site, does not stand for the rest. If the version also changes the protocol or the point list, the watch has to include whether the platform can still parse the new reports. An online lamp is not enough. When something is wrong, batches that have not started should be able to stop, and devices that already have the new image should be able to return to the old version, either inside a maintenance window or immediately. Do not leave those two rhythms ambiguous inside one switch. Pass or fail should leave a reason a person can read, not only a button that was clicked.
When the sample does not cover the devices about to go full
A percentage draw that ignores distribution can land entirely on one model and one room. Boot failures on the other models appear only at the full rollout. Using "recently online" as the sampling condition leaves out devices that sleep for a long time and devices on the worst links, and those are often the ones that time out during an upgrade. A watch that counts only download success, and not the service messages after reboot, treats a program that never comes up as a pass. Widening the range under the previous batch's old task id lets a failed retry upgrade a device that was already confirmed. Stopping the batch only stops new deliveries. A device that has finished downloading and has not rebooted will still switch itself on the next power-up. If the rollback package was not prepared with the gray task, the moment a return is needed is the moment you find the old version has been cleaned up. Different batches signed with different keys, so the earlier batch verifies and the later one does not, get misread as a network problem. Each batch's list, the moment watching started, and the reason for a stop should stay on the task, so it is possible later to say why the rollout did not grow. The measures to watch should be written down before the batch opens. Do not pick the flattering curve after the result is in. After a stop, no device should quietly enter the next batch unless the watch scope is set again and the reason is recorded.