Skip to content
AKZ

01Interactive exhibit

Stages

Optional / parallel path

Registry · release.json

Detect the application

Finds which operator application is installed, from an explicit setting, from its release file or from its installed package. If several match, it waits for the application to be named.

02

Context & challenge

Industrial touch panels run one of several operator applications, and some applications ship on more than one release track. Keeping every panel on the right version cannot rely on someone updating each device by hand.

The update path also has to be understandable from the application itself: an operator should be able to see whether a newer version exists and how an installation is going.

03

Approach

One small service per device owns the whole update path: application detection, release-track resolution, release discovery, package download, optional verification, installation, status and backup metadata. The operator applications only talk to its HTTP API.

Which applications the service can update is data, not code. A registry lists each application's package name, release source and optional tracks, so adding an application is a registry change.

04

My role

I designed and built the service, its packaging and its CI workflow.

05

What was delivered

Detection and release tracks

Identifies the installed application and resolves which release track it follows, so the right package is considered. A demo launcher can pin the application and track when several are installed.

Release discovery

Reads the release source, skips drafts and prereleases, and selects the highest valid semantic version that has the expected package. A manifest source is supported as well.

Install and status

Downloads the Debian package, verifies it when a digest is available, installs it and reports progress with stable error codes. Transient network failures are retried once.

Backup and restore

Records the version being replaced so the previous release can be installed again on request.

06

Engineering decisions

One owner for the update path

The service owns detection, resolution and installation. The product applications own their own interface, machine APIs and packages.

Applications are data

A registry describes the applications and tracks the service can update, so new applications do not need a new service build.

Designed for the device

It runs as a systemd service on ARM64 Debian, ships as a Debian package and is covered by a package smoke test in CI.

Honest recovery

Restore reinstalls a recorded version. It is not presented as a transactional rollback.

07

Status & outcome

A single update service shared by the UTEST operator applications, with one update path for every release track.

08

Attribution & publication notes

  • The service installs software with elevated privileges and is meant to sit behind the device's own web server. Repository is private.
  • No claims of zero-downtime updates, atomic installs or guaranteed rollback are made.

Next project

UTEST Web App Launcher