Delivering Software Updates: The Last Mile of Product Development

Shipping your product to customers is where some real challenges in software development begin. Once it lands in customers’ hands, delivering the expected and necessary software updates can be a complicated task.

Here’s a breakdown of some key considerations to keep your product, and your customers, running smoothly, even after your product has shipped.

Getting updates to users

The way you handle software updates depends on both your device and your users. Some products rely on users to manually update the device firmware. This approach puts more work on the end user but can be an acceptable simple first step if your user base is technically savvy. It eliminates some complexity to have your customers download the firmware directly from your website and install it themselves via USB, onboard storage, or even through a desktop app.

If you go this route, however, you’ll want to think about implementing safety measures. Corrupt firmware files or interruptions in the update process can brick the device. Consider using dual A/B firmware loads to ensure there’s always a working version available if the update fails.

The alternative to manually delivered updates is over-the-air (OTA) installation. This has a lot of advantages, from hands-off operation to remote updates. They can also be made more resilient to interruptions since the software can validate the image is on the system before installing it. The biggest downside is the complexity of programming an OTA solution, as well as mandating that the device has access to the internet (although it’s increasingly rare that things don’t).

To auto-update or not?

Automatic updates sound like a great idea – customers always get the latest features and security patches without having to lift a finger. But it's important to weigh the pros and cons. Auto-updates can force your device to go offline for maintenance, which might annoy users if it happens at the wrong time. Imagine a smart keyless lock performing an update while someone is locked out of their home or a medical device updating itself during a critical procedure.

For devices that are constantly in use or have critical uptime requirements, it’s worth considering an opt-in model for updates. Even if auto-updates are the default, make sure the feature can be easily turned off or postponed by the user.

Keeping data intact

Updates should never wipe out user data. It’s one thing to install fresh code, but if configuration files or user data are lost in the process, you’ve got a problem. To avoid this, you need to manage your file versions carefully and develop a process for migrating data forward in a way that’s backwards-compatible if necessary.

If your product allows rolling back to earlier versions of firmware, ensure that data migration works both ways. For configuration files, text formats like JSON can be a lifesaver. If you need to roll back, any keys added by newer versions can be ignored. When updating, any missing keys mean that you need to provide a default value. Plus JSON files are human-readable, which is especially useful if you need to debug configuration files directly.

Preparing your software for the world

When it’s time to release an update, you’ll need a robust process in place. First things first: every update needs a unique version number. This is essential for tracking issues and ensuring that customers are using the correct version of the software.

To streamline the process, compress your firmware files to save space during download and storage. And don’t forget security: all your update files should be digitally signed to prevent tampering or corruption. Maintaining a well-organized in-house library of all releases, along with tagging customer-facing versions in your source control, will make life easier when you need to dig up old binaries for testing or debugging.

Even if your product uses containers like Docker, the same principles apply. How will customers get the updates? How will the integrity of the files be verified? And, just as important, how can you ensure that the process of getting these files into your device is bulletproof?

Testing before shipping

Quality assurance is crucial, and there’s no substitute for testing the entire product before it hits customer hands. Unit testing by developers is important, but you need to go beyond that. Whether it’s an in-house team or outsourced specialists, someone needs to test the fully integrated product.

Once your product is in the field, you’ll also need a plan to recover from potential bugs in the update process. Can your customer reset the device to factory defaults and restore it from a stable firmware version? If so, make sure that reset process covers everything, from the obvious to the less visible, like persistent hardware or file system states that users might not even know exist.

Planning for future updates

Before your product is in the field, you’ll need to decide how often you want to push bug fixes and security patches. Will updates roll out on a regular schedule, or will you wait until a critical mass of fixes is ready? Some customers may even require their own private branches for high-priority fixes, depending on their contracts or support agreements.

It’s worth discussing these considerations with your team upfront so that everyone’s aligned on the update strategy. This can help avoid last-minute scrambles and keep your customers happy in the long run.

Final thoughts

Shipping a product isn’t just about getting it into the customer’s hands. It’s about ensuring that, once it’s there, it can continue to evolve, improve, and remain secure. Whether through manual updates or automated processes, thoughtful planning and thorough testing will make sure your product stays at its best long after it’s left your warehouse.

By keeping these best practices in mind, you can ensure that your embedded Linux device not only works today but will continue to function – and improve – well into the future.

For more on related topics, including important up-front decisions that need to be made at the outset of a project, explore our whitepaper, Designing Your First Embedded Linux Device: Framing the Development Process.