Record the release composition
Retain the application/service versions, container image tags or digests, model and scenario versions, configuration, schema version and migration steps. Product release and analytical model version are separate identifiers.
Validate before rollout
Check compatibility and migration instructions, then test the candidate on representative assets and the intended hardware. Compare against the previous version using the same acceptance criteria.
Roll out in stages
Begin with a limited scope, verify source access and event delivery, and monitor resource usage and operator outcomes. Expand only after the stage passes its checks.
Prepare rollback
Retain previous images, packages and configuration. Take a private backup before changes that affect data. Determine whether a database migration is reversible; a service-image rollback alone may not restore schema compatibility.
Close the change
Record what changed, the validation evidence, any known limitations and the owner. Confirm that monitoring, backup and documentation reflect the installed state.
Contract snapshots and model rollback dependencies
Alongside the service/image and schema manifest, retain the installed environment’s OpenAPI snapshot, scenario version_id and dependencies, and the control asset, launch_uuid and result. These link client compatibility and analytical behavior to the exact release.
A grouped model replacement through MM creates new versions of successfully updated scenarios. Reverting to an older model alone does not complete rollback: inspect which scenario versions are actually assigned to cameras.