Linux OTA update for a fleet of devices - best practice
To update the software of a fleet of Embedded Linux based devices there are a few different approaches that may provide the capability with zero integration and learning curve. To deploy an OTA software update in the right way, we need to create 2 groups, one for checking and testing the deployed update and the seconde group - production, that include the devices that are already in the field, running as they should. This simple design makes OTA software updates reliable, quick and with much fewer mistakes.
The usual, standard software update for Linux based devices that are in production is a file system based update which includes updating the application configuration files, fixing software bugs or upgrade features, all require to deploy new files and replace them with the old ones (the current running files). There are also other cases, where we will need to have the option to install a software package remotely using the known software managers and be sure that the update has been done successfully.
The recommended way of deploying an OTA software update is by creating a software update recipe based on the next steps:
1. Run bash commands to prepare your device for a software update. This may include a command for stopping the application service/process.
2. Deploy new software files, directories, and configurations. Those will replace the current files.
3. Install and upgrade new software packages if needed, in case the new updated code uses new packages.
4. Opposite to the first step, here we will start the application service/process and any other related commands.
Not less important is what will happen in case of a software update failure. As part of the recipe, a rollback functionality has to be defined to make sure files and software packages will rollback to the previous version in case of any update failure from any kind of reason.
After a successful OTA software update, there are a few other great tools that may help us understand how the devices behave - monitoring CPU, RAM, and DISK usage as well as viewing important live parameters from the device's application which may tell us more about the application status. In some cases, we will even need to be able to do a deep debugging to one of the devices, this can be done using a remote control tool which provides the capability to access the device terminal remotely.
All of those tools and many others can be found at Upswift.io IoT platform.