See Overview for the version order every delivery follows and how background migrations run after an upgrade.
Checking the version mapping
Every chart release states the Deckhouse Code version it deploys. Check it before upgrading:
helm show chart deckhouse-code --version <CHART_VERSION>Upgrading the release
helm repo update
helm upgrade code deckhouse-code \
-n code \
-f values.yaml \
--version <CHART_VERSION>The command reuses the existing values.yaml. Follow the version order from Overview when the mapping spans more than one Deckhouse Code version; skipping a version can leave a later migration unable to run.
Waiting for migrations
A migrations job runs once per upgrade, before the components that depend on the new database schema restart. Check its progress:
d8 k -n code get jobs
d8 k -n code logs job/<MIGRATIONS_JOB_NAME>Some migrations continue in the background after the job completes; Overview describes when the next upgrade can start.
Rolling back
helm rollback code <REVISION>helm rollback reverts the release’s Kubernetes objects only. It does not reverse a database schema change made by the upgrade’s migrations.
When the upgrade you’re rolling back changed the schema, restore the backup taken before the upgrade after the rollback completes; see Helm Chart in Backup and restore.