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 revert your deployment to a known good state while you investigate the cause of the failure. You can roll back to any deploy in the last three months regardless of your DAG code or Deployment settings. However, rollbacks are only supported for Runtime 5.0.0 and above or its equivalent Airflow version, 2.3.0 and above.
deployment.images.push or system.deployments.images.push to roll back a Deployment.global.dagOnlyDeployment.enabled=TrueTo use deploy rollbacks, you must have them enabled for your entire installation. This configuration allows individual Deployment users with sufficient permissions to optionally enable them in specific Deployments.
Configure the following values in your values.yaml file:
After you set this configuration, you can enable deploy rollbacks for individual Deployments. This configuration also enables cleanup of any deploy information that are older than 90 days. See Apply a Config Change for more information on how to modify these values.
If deploy rollbacks are configured for your installation, you can enable them in individual Deployments through the Deployment Settings page.
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:
Logs related to the rollback are exported to Elasticsearch.