Redeploy and Roll Back a Deployment with AWS CodeDeploy
AWS CodeDeploy rolls back deployments by redeploying a previously deployed revision of an application as a new deployment. These rolled-back deployments are technically new deployments, with new deployment IDs, rather than restored versions of a previous deployment.
Deployments can be rolled back automatically or manually.
You can configure a deployment group or deployment to automatically roll back when a deployment fails or when a monitoring threshold you specify is met. In this case, the last known good version of an application revision is deployed. You configure automatic rollbacks when you create an application or create or update a deployment group.
When you create a new deployment, you can also choose to override the automatic rollback configuration that were specified for the deployment group.
You can use Amazon Simple Notification Service to receive a notification whenever a deployment is rolled back automatically. For information, see Monitoring Deployments with Amazon SNS Event Notifications.
For more information about configuring automatic rollbacks, see Configure Advanced Options for a Deployment Group.
If you have not set up automatic rollbacks, you can manually roll back a deployment by creating a new deployment that uses any previously deployed application revision and following the steps to redeploy a revision. You might do this if an application has gotten into an unknown state. Rather than spending a lot of time troubleshooting, you can redeploy the application to a known working state. For more information, see Create a Deployment.
If you remove an instance from a deployment group, AWS CodeDeploy does not uninstall anything that might have already been installed on that instance.
Rollback and Redeployment Workflow
When automatic rollback is initiated, or when you manually initiate a redeployment or manual rollback, AWS CodeDeploy first tries to remove from each participating instance all files that were last successfully installed. AWS CodeDeploy does this by checking the cleanup file:
file (for Amazon Linux, Ubuntu Server, and RHEL instances)
file (for Windows Server instances)
If it exists, AWS CodeDeploy uses the cleanup file to remove from the instance all listed files before starting the new deployment.
For example, the first two text files and two script files were already deployed to an Amazon EC2 instance running Windows Server, and the scripts created two more text files during deployment lifecycle events:
c:\temp\a.txt (previously deployed by AWS CodeDeploy) c:\temp\b.txt (previously deployed by AWS CodeDeploy) c:\temp\c.bat (previously deployed by AWS CodeDeploy) c:\temp\d.bat (previously deployed by AWS CodeDeploy) c:\temp\e.txt (previously created by c.bat) c:\temp\f.txt (previously created by d.bat)
The cleanup file will list only the first two text files and two script files:
c:\temp\a.txt c:\temp\b.txt c:\temp\c.bat c:\temp\d.bat
Before the new deployment, AWS CodeDeploy will remove only the first two text files and the two script files, leaving the last two text files untouched:
c:\temp\a.txt will be removed c:\temp\b.txt will be removed c:\temp\c.bat will be removed c:\temp\d.bat will be removed c:\temp\e.txt will remain c:\temp\f.txt will remain
As part of this process, AWS CodeDeploy will not try to revert or otherwise reconcile any actions
taken by any scripts in previous deployments during subsequent redeployments, whether manual or
automatic rollbacks. For example, if the
d.bat files contain logic to not re-create the
f.txt files if they already exist, then the old versions of
f.txt will remain untouched whenever AWS CodeDeploy
d.bat in subsequent deployments. You
can add logic to
d.bat to always check for
and delete old versions of
creating new ones.