Update Zulip Server version: Difference between revisions
No edit summary |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 20: | Line 20: | ||
== Upgrade Procedure == | == Upgrade Procedure == | ||
'''Important Notes''' | '''Important Notes''' | ||
This procedure is taken from the official doc, if official doc has been updated this checklist should be updated to | This procedure is taken from the official doc, if official doc has been updated this checklist should be updated too | ||
'''Note on error emails during upgrade:''' Background workers from previous deployments may still be running when the upgrade restarts PostgreSQL. These workers will lose their database connection and crash, triggering error alert emails. This is expected behaviour and not a sign of anything wrong. One way to avoid this is to explicitly stop all Zulip services before running the upgrade script. | |||
# Fetch the latest build <code>curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz</code> | # Fetch the latest build <code>curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz</code> | ||
# Run the upgrade <code>/home/zulip/deployments/current/scripts/upgrade-zulip zulip-server-latest.tar.gz</code> | # Run the upgrade <code>/home/zulip/deployments/current/scripts/upgrade-zulip zulip-server-latest.tar.gz</code> | ||
| Line 28: | Line 31: | ||
# Update the settings.py file following the method described [https://zulip.readthedocs.io/en/latest/production/upgrade.html#updating-settings-py-inline-documentation here] | # Update the settings.py file following the method described [https://zulip.readthedocs.io/en/latest/production/upgrade.html#updating-settings-py-inline-documentation here] | ||
# Once you've made sure everything is running as expected remove the snapshot and maintenance period | # Once you've made sure everything is running as expected remove the snapshot and maintenance period | ||
# Inform the team that the upgrade is complete and that any error emails received during the upgrade window are expected and can be ignored. | |||
== Note == | == Note == | ||
See this message for configuration details regarding email: https://chat.dsinternal.net/#narrow/channel/4-SRE-.23.23-Non-critical/topic/Zulip.20inbound.20email.20bounces/near/62829 | See this message for configuration details regarding email: https://chat.dsinternal.net/#narrow/channel/4-SRE-.23.23-Non-critical/topic/Zulip.20inbound.20email.20bounces/near/62829 | ||
Latest revision as of 08:44, 22 April 2026
Context: This procedure was written at the time of Zulip 11.4, and applies to upgrades performed on the chat.dsinternal.net server.
Important Notes
- It is possible (and supported) to upgrade across multiple versions at once — there is no need to install each intermediate release.
- Always consult the official Zulip upgrade documentation first. It supersedes this checklist:
https://zulip.readthedocs.io/en/latest/production/upgrade.html
- Make sure to note any important and relevant details concerning the next upgrade(s) reading the upgrade notes for every upcoming major version:
https://zulip.readthedocs.io/en/latest/overview/changelog.html
- In our case we're following the upgrading-to-a-release method not the upgrading-from-a-git-repository one.
- Read any version-specific upgrade notes in the official docs before proceeding.
Pre-upgrade Steps
- Read the upgrade notes and prepare accordingly if some specific actions need to be taken
- Make sure the Debian and PostgreSQL versions are compatible with the upcoming update
- Schedule and announce the maintenance window
- Create a maintenance period in Zabbix
- Create a backup and/or snapshot
Upgrade Procedure
Important Notes This procedure is taken from the official doc, if official doc has been updated this checklist should be updated too
Note on error emails during upgrade: Background workers from previous deployments may still be running when the upgrade restarts PostgreSQL. These workers will lose their database connection and crash, triggering error alert emails. This is expected behaviour and not a sign of anything wrong. One way to avoid this is to explicitly stop all Zulip services before running the upgrade script.
- Fetch the latest build
curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz - Run the upgrade
/home/zulip/deployments/current/scripts/upgrade-zulip zulip-server-latest.tar.gz - Monitor the process, expect temporary CPU and memory spikes right after the upgrade due to migrations and cache rebuilds. You probably want to wait for things to settle down before going on to next steps.
Post-upgrade Tasks
- Update the settings.py file following the method described here
- Once you've made sure everything is running as expected remove the snapshot and maintenance period
- Inform the team that the upgrade is complete and that any error emails received during the upgrade window are expected and can be ignored.
Note
See this message for configuration details regarding email: https://chat.dsinternal.net/#narrow/channel/4-SRE-.23.23-Non-critical/topic/Zulip.20inbound.20email.20bounces/near/62829