Remember instance refs and add safe rollback choices - #530
Conversation
|
Warning Review limit reached
Next review available in: 31 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
📝 WalkthroughWalkthroughThe PR adds a Django migration rollback command, a rollback utility with migration and backup-restore modes, per-instance Git ref tracking, deployment history, release retention, and related deployment documentation and tests. ChangesDeployment rollback and release tracking
Estimated code review effort: 5 (Critical) | ~90+ minutes Sequence Diagram(s)sequenceDiagram
participant Operator
participant rollback.sh
participant Django
participant Database
participant Release
Operator->>rollback.sh: select target release and rollback mode
rollback.sh->>Django: plan or apply reverse migrations
Django->>Database: inspect or update migration state
rollback.sh->>Database: restore or swap database when requested
rollback.sh->>Release: switch instance release
rollback.sh-->>Operator: report rollback result
Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@scripts/README.md`:
- Line 50: Update the preceding predeploy_backup.sh description to state that
its paired database backup supports rollback.sh --restore-backup, replacing the
outdated “switch release, psql restore” wording while leaving the rollback.sh
entry unchanged.
In `@scripts/rollback.sh`:
- Around line 109-113: Update stop_services to remove the || true failure
suppression from all three systemctl stop commands, and verify each service is
inactive before returning so rollback cannot proceed to database changes while
application processes remain active.
- Around line 101-105: Update cleanup() so a failed dropdb for RESTORE_DB
reports the database name to stderr and returns a non-zero status; remove the ||
true suppression while preserving TARGETS_FILE removal and successful cleanup
behavior.
- Around line 90-92: Update the current-SHA guard in the rollback mode handling
so it rejects matching CURRENT_SHA and TARGET_SHA only for latest-db operations,
while allowing --restore-backup to proceed and recover the current release’s
safety backup. Add a regression test covering current-release --restore-backup
success and preserve the existing rejection for latest-db.
In `@scripts/server/instance.sh`:
- Around line 621-622: Move the write_deploy_state call for the "create" action
out of the early setup path and into the final successful-create path in
instance creation. Place it after all required migrations, configuration, and
service operations complete, so deploy-state.env and deploy-history.tsv are
updated only when creation succeeds.
In `@scripts/server/README.md`:
- Around line 134-148: The Step 3 deployment sequence description must reflect
per-instance refs: update the `deploy.sh` workflow text to say it resolves each
target instance’s ref and builds or reuses one release per unique SHA, including
that a bare `--all` deployment may use multiple refs.
In `@scripts/server/release-utils.sh`:
- Around line 77-85: Update the command constructed for sudo in the release
setup flow to enable errexit, nounset, and pipefail with set -euo pipefail
before either source command. Keep the existing virtualenv activation,
environment loading, exports, directory change, and management command execution
unchanged.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 348fbd9b-f6a5-41dd-b16c-5c8f81f5fa03
📒 Files selected for processing (12)
apps/workflow/management/commands/rollback_migrations.pyapps/workflow/tests/test_rollback_migrations.pydocs/adr/0029-servers-run-the-production-branch.mddocs/updating.mdscripts/README.mdscripts/predeploy_rollback.shscripts/rollback.shscripts/server/README.mdscripts/server/deploy.shscripts/server/instance.shscripts/server/release-utils.shscripts/test_release_utils.sh
💤 Files with no reviewable changes (1)
- scripts/predeploy_rollback.sh
1 participant
Summary
--restore-backup)Why
Instance branch tracking was previously only a prose convention while
deploy.shusedorigin/productionglobally. The instance state exposed only the latest current/previous pair, and rollback always restored a database snapshot. That made it too easy to deploy the wrong branch to UAT and made a Tuesday rollback unnecessarily discard data written since Monday's release.This gives the operator the information and choices needed to make that judgment directly: see the installed SHA history, choose a target SHA, and either reverse the latest database's migrations or restore the paired snapshot.
Jira: KAN-336
Operator commands
Both rollback modes show recent deployment history, require confirmation, take a fresh safety backup, validate the target release, and leave services stopped on a failed reverse migration.
Validation
bash scripts/test_release_utils.shpython manage.py test apps.workflow.tests.test_rollback_migrationsUAT after merge
The first deploy must explicitly bootstrap the tracked ref for the existing UAT instance:
sudo scripts/server/deploy.sh msm-uat --ref origin/main sudo scripts/server/instance.sh history msm uatThen test both choices against a SHA shown in the history:
sudo scripts/rollback.sh msm-uat <previous-sha>and verify the migration plan, application health, database checks, and new history entry.sudo scripts/rollback.sh msm-uat <new-release-sha> --restore-backupto restore the safety snapshot paired with the new release, then verify application health and history again.sudo scripts/server/deploy.sh msm-uatand confirm the instance still reportsorigin/mainas its tracked ref.If the selected releases have identical migration leaves, step 1 proves the code-only latest-database path. Select a known earlier reversible migration if an actual reverse migration needs to be exercised in UAT.
Summary by CodeRabbit
New Features
--refselection.rollback.shfor rolling back releases while retaining the latest database or restoring a paired backup.Documentation