Question
Limits of DisCloud Rollback: Database Schema and Environment Variable Consistency
Zo Byte
0 reputation · 14 Jul 2024, 08:44 UTC
111.4K views
Loading…
0 reputation · 14 Jul 2024, 08:44 UTC
When a deployment on DisCloud fails, the platform’s web‑based log viewer aggregates the agent’s output, showing status messages, timestamps, and a truncated snippet of the last executed command. The UI offers a Rollback button that attempts to revert the site to the previous successful deployment, but the logs do not clearly indicate whether the rollback succeeded or if any files remain in an inconsistent state.
The current documentation does not specify whether the rollback process restores database schema changes or environment variable updates. This ambiguity can leave an application in a partially updated state after a failed deployment, potentially causing runtime errors or data inconsistencies that are hard to trace back to the deployment event.
Given this uncertainty, I need to understand the exact behavior of the rollback feature and how to verify its success through logs or other evidence. Specifically:
31775 reputation · 14 Jul 2024, 18:03 UTC
1. Does DisCloud’s rollback preserve database schema changes made during the failed deployment?
No. Rollback only reverts the code artifact to the previous successful commit. Any schema migrations that were applied during the failed deployment remain in the database.
2. Are environment variable updates reverted to the previous state when a rollback is performed?
No. The platform keeps the last successful set of environment variables; rollback does not roll them back.
3. Which log entries or UI indicators confirm that a rollback has fully restored the application?
Look for a log line that ends with Rollback succeeded. In the UI, a green success badge next to the deployment entry appears only when the rollback completes fully; a gray or red badge indicates a partial or failed rollback.
discloudRollback initiated entry followed by either Rollback succeeded or Rollback failed.schema_migrations or flyway_schema_history) to confirm that the migration from the failed deployment is absent.Rollback succeeded entry; ensure the log ends with this marker.To tailor the migration‑table query, please let us know which migration tool your project uses (e.g., Flyway, Liquibase, Rails ActiveRecord). This will help you locate the exact table to inspect for pending migrations.
Use comments to ask for clarification. Post a solution as an answer.
31,775 reputation · 14 Jul 2024, 09:54 UTC
DisCloud treats each deployment as an immutable zip artifact; rolling back simply selects the previous artifact and restores only those files. Anything outside that artifact—such as applied database schema migrations, changes to managed DB data, or environment‑variable key/value pairs stored in the platform configuration—is not touched by the rollback operation. Consequently, after a rollback your code may be at version N‑1 while the database is still at version N (or later) and the env vars remain as they were set during the failed deploy. To confirm a consistent state you need to check three independent sources: (1) the file manifest returned by the DisCloud API for the active deployment (compare its SHA‑256 list with the manifest of the intended previous version), (2) the migration table in your database to ensure no new migration rows from the failed deploy are present, and (3) the current env‑var set via the DisCloud dashboard or API against the snapshot you saved before the deploy. If all three match the expected prior state, the rollback can be considered successful; otherwise you must manually run down‑migrations or reset env vars.