Upgrades

Before you upgrade

• Take a backup and confirm it completed. See the backup guide.
• Read the release notes for migration warnings and any configuration that has changed.
• Pin the version tag in the compose file rather than using latest, so what you deploy is what you tested.
• Upgrade staging first if you have one. If you do not, upgrade on a Friday morning rather than a Friday evening.

The upgrade

# 1. back up first
sh /opt/edc/backup.sh

# 2. pin the new version
sed -i 's|employeedesk/app:.*|employeedesk/app:1.9.0|' docker-compose.yml

# 3. pull and restart
docker compose pull
docker compose up -d

# 4. migrations run automatically on start
docker compose logs -f app | grep -i migrat

# 5. confirm
curl -fsS https://hr.yourcompany.com/api/health

Rollback

Rolling back the application image is easy. Rolling back a database migration is not, which is why the backup is step one rather than step five.

1. If the application fails to startRepin the previous tag and restart. If migrations had not completed, this is sufficient on its own.
2. If migrations completed and the release is wrongRestore the database from the pre-upgrade backup and repin the previous image tag. Data written after the upgrade is lost, which is why you should notice quickly.
3. If only one feature misbehavesTell us before rolling back. A configuration fix is usually faster than a restore and does not lose the day.

Upgrading the desktop fleet

Publish the new tracker build to your update feed and installed clients pick it up on their next check, downloading in the background and applying at the next restart. There is no per-machine action. Keep the server and tracker versions within one minor release of each other.

Version support

• Updates are included for as long as the annual licence is active.
• Perpetual licences include one year of updates, then 18% annual maintenance to continue receiving them.
• Security fixes are backported to the previous minor release.

Related