Updates & version upgrades

Admin

Goal

Raise an existing installation to a new version – the procedure differs by operating mode.

Web / Docker

The web deployment is a single container image (API + Blazor-WASM together). Images are built tag-triggered in CI and pushed to the registry as :latest and :<tag> (e.g. :v0.29.0).

Bump the version, tag the commit, push the tag → CI builds and pushes the image.
In the deployment (Helm in the separate evanto-deployment repo, branch production) set the image tag to the new version and roll it out.
On startup check: /alive and /ready (see Monitoring & health checks).

External services (Qdrant, Presidio) run separately and are updated independently.

Desktop (macOS)

The desktop app is updated manually (no auto-update): install the new installer package. The build runs via macos/build-macos.sh (dotnet publish, self-contained; help content is placed into the app bundle).

Obtain and install the new app bundle/package.
Start the app – DbInitializer brings the schema up to date and applies updated help vaults.

Before a desktop version change, create a backup.

Help content (help-de / help-en)

The in-app help is versioned via a .help-version file per vault. On startup the rule is: fresh install → copy; same version → nothing; newer bundled version → overwrite. So to ship new help, bump .help-version and ship it with the image/bundle.

What to watch out for

Schema changes need two spots: an EF migration and a matching EnsureColumnExistsAsync entry in the DbInitializer. On startup only DbInitializer.InitializeAsync runs, not MigrateAsync.
Model catalog: before releases, update the bundled snapshot (docs/catalog-snapshot.md).
Changed index.html? In Aspire operation the host must be restarted – a plain build is not enough.
Version jump + restore: always restore a backup into an equally new or newer app version (see BW-01).

Verification

/health green (web), sign-in possible, knowledge search returns hits.
Help shows the new content; admin tabs load without errors.