The Overview tab in the Astro UI shows you a record of all code deploys to your Deployment. Use this page to track the development of a Deployment and to pinpoint when your team made key changes to code.
Astronomer stores the image and Dags for all deploys made in the last 90 days. You can trigger a rollback to any of these deploys so that your Deployment starts running a previous version of your code.
Deploy rollbacks are an emergency option if a Deployment unexpectedly stops working after a recent deploy. For example, if one of your Dags worked in development but suddenly fails in a mission-critical production Deployment, you can roll back to your previous deploy to quickly get your pipeline running again. This allows you to troubleshoot the issue more thoroughly in development before redeploying to production. You can roll back to any deploy in the last three months regardless of your Runtime version, Dag code, or Deployment settings.
For each deploy, the Deploy History table shows the user who made the deploy, when they made the deploy, what image they used, the type of deploy, and any descriptions they added to the deploy.
There are different types of deploys, which are shared in the Deploy History table. You can read more about the different deploy options in Deploy code to Astro. These deploy types include:
Adding a description to a deploy is a helpful way to let other users know why you made a deploy and what the deploy contains. Descriptions appear in your deploy’s entry in the Deploy History table.
To add a description to a deploy, specify the --description flag when you run astro deploy. For example:
You can roll back to any deploy within the last three months. If your last deploy was more than three months ago, you can only roll back to that deploy. After the rollback completes, the Deploy History table shows your rollback deploy as the most recent deploy and includes both your rollback description and rollback deploy time. Your Docker image tag, Dag bundle name, and dbt bundles are the same as the previous version you rolled back to. The historic deploy that you rolled back to still appears in chronological order in the table.
For example, consider a user who, on November 8, 2023 at 13:00, rolled back to a deploy from November 6, 2023 at 14:00. At the top of the Deploy History table, an entry for the rollback deploy would have the following information:
A deploy rollback is a new deploy of a previous version of your code. This means that the rollback deploy appears as a new deploy in Deploy History, and the records for any deploys between your current version and rollback version are still preserved. In Git terms, this is equivalent to git revert.
When you trigger a rollback, the following information is rolled back:
The following information isn’t rolled back:
A rollback’s effect on running tasks depends on whether the rollback downgrades your Deployment:
Remote Execution Agent Deployments require special handling for rollbacks.
The standard Astro deploy rollback doesn’t manage Agent versions. This means you must manually roll back Remote Execution Agents before rolling back your Deployment in Astro.
Failing to do so can result in incompatibility between your Remote Agent and Astro Deployment causing interrupted workflows.
Update each Remote Execution Agent to the desired target Runtime/Agent version by reverting their containers to the appropriate image. Ensure all agents are successfully reverted before proceeding to the next step.
Trigger a Astro Deployment rollback to a deployment that is compatible with your Remote Agent’s updated version.