mirror of
https://github.com/zulip/zulip.git
synced 2026-06-06 21:12:33 +08:00
26189578c6
Most of what makes a Zulip migration tricky to write follows from how Zulip Cloud deploys: staging and production share a database, staging deploys first and runs the migration against the shared DB, production deploys some time later, and Django processes restart in a rolling fashion. Together these mean migrations must be safe for the previous release's code to keep running against, and that staging-time problems are also live production problems. The previous version of this page didn't describe any of that, and as a result didn't motivate most of the rules contributors need to follow. Rework the page around the deploy model so each rule traces back to a property of how migrations actually run on Cloud. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| install-docker.md | ||
| shared-vagrant-errors.md | ||
| unix-troubleshoot.md | ||
| vagrant-halt.md | ||
| vagrant-rebuild.md | ||
| vagrant-resume.md | ||
| vagrant-ssh.md | ||
| vagrant-up.md | ||
| vagrant-update.md | ||
| vscode-vagrant.md | ||
| winvm-troubleshoot.md | ||
| wsl-rebuild.md | ||
| wsl-troubleshoot.md | ||