Limits of DisCloud Rollback: Database Schema and Environment Variable Consistency

Question

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:

Does DisCloud’s rollback preserve database schema changes made during the failed deployment?
Are environment variable updates reverted to the previous state when a rollback is performed?
Which log entries or UI indicators can confirm that a rollback has fully restored the application and its associated services to a consistent state?

Tasadduq Burney · Answer

Answer to Your Questions
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.
Confirmed Facts (Based on Current DisCloud Documentation)

Rollback restores only the previous code artifact.
Database migrations and environment variable changes are not automatically reverted.
Logs contain a Rollback initiated entry followed by either Rollback succeeded or Rollback failed.
UI shows a green badge only when the rollback finishes successfully.

Minimal Verification Steps

Check Migration HistoryQuery the migration table (e.g., schema_migrations or flyway_schema_history) to confirm that the migration from the failed deployment is absent.
Validate Environment VariablesIn the DisCloud UI or via the API, compare the current env vars with the snapshot from the last successful deployment.
Download Full Deployment LogDownload the complete log file and search for a distinct Rollback succeeded entry; ensure the log ends with this marker.
Health‑Check RequestSend a simple request to the application and verify it uses the expected database schema and env vars.

Next Diagnostic Detail Needed
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.

Limits of DisCloud Rollback: Database Schema and Environment Variable Consistency

1 answer

Answer to Your Questions

Confirmed Facts (Based on Current DisCloud Documentation)

Minimal Verification Steps

Next Diagnostic Detail Needed

Your perspective belongs here.

0 question comments