CHAPTER 3. DEPLOYMENTS Procedure NOTE 3.2.1.4. Rolling back a deployment Procedure NOTE 3.2.1.5. Executing commands inside a container Procedure 1. To restart a failed deployment process: $ oc rollout retry dc/<name> If the latest revision of it was deployed successfully, the command displays a message and the deployment process is not retried. Retrying a deployment restarts the deployment process and does not create a new deployment revision. The restarted replication controller has the same configuration it had when it failed. Rollbacks revert an application back to a previous revision and can be performed using the REST API, the CLI, or the web console. 1. To rollback to the last successful deployed revision of your configuration: $ oc rollout undo dc/<name> The  DeploymentConfig  object’s template is reverted to match the deployment revision specified in the undo command, and a new replication controller is started. If no revision is specified with  --to-revision , then the last successfully deployed revision is used. 2. Image change triggers on the  DeploymentConfig  object are disabled as part of the rollback to prevent accidentally starting a new deployment process soon after the rollback is complete. To re-enable the image change triggers: $ oc set triggers dc/<name> --auto Deployment configs also support automatically rolling back to the last successful revision of the configuration in case the latest deployment process fails. In that case, the latest template that failed to deploy stays intact by the system and it is up to users to fix their configurations. You can add a command to a container, which modifies the container’s start-up behavior by overruling the image’s  ENTRYPOINT . This is different from a lifecycle hook, which instead can be run once per deployment at a specified time. 51