### Deployment Rollback Procedure: Web Application (AWS EC2)
**1. Incident & Trigger for Rollback**
* **Deployment ID/Version to Rollback FROM:** `v3.1.2`
* **Target Rollback Version:** `v3.1.1`
* **Trigger/Reason for Rollback:** [e.g., Critical Bug Detected, Performance Degradation, Unexpected Service Errors]
* **Date & Time Initiated:** [YYYY-MM-DD HH:MM UTC]
* **Initiated By:** [Your Name]
**2. Pre-Rollback Checks & Preparations**
* **Notify Stakeholders:** Inform clients/team members about potential service interruption during rollback.
* **Identify Last Known Good Configuration:** Confirm `v3.1.1` Docker image tags, database backups/migrations.
* **Verify Access:** Ensure SSH access to EC2 instances, AWS console access for relevant services (ECS, RDS, EC2, CloudWatch).
* **Backup Current State (Optional but Recommended):**
* Take a snapshot of the `v3.1.2` EC2 instance if feasible.
* Perform a quick database backup (`pg_dump`) if no recent automated backup exists.
**3. Rollback Procedure**
**Step 3.1: Halt New Traffic (if applicable)**
* If using a Load Balancer (e.g., ALB), temporarily remove instances running `v3.1.2` from the target group or disable auto-scaling to prevent new traffic to problematic instances.
**Step 3.2: Database Rollback (if necessary)**
* **CRITICAL:** Only proceed if `v3.1.2` introduced database schema changes that are incompatible with `v3.1.1` or if data corruption occurred.
* **Option A (Schema Rollback):** Apply down migrations for `v3.1.2` changes (e.g., using `Alembic` or `Flyway` if set up).
* `ssh ec2-user@your-ec2-instance`
* `cd /path/to/app`
* `docker-compose exec app python manage.py db downgrade <migration_id_to_v3.1.1>` (Example for Flask-Migrate)
* **Option B (Data Restore):** Restore a pre-`v3.1.2` database backup if data integrity is severely compromised.
* `aws rds restore-db-instance-from-db-snapshot --db-snapshot-identifier [SNAPSHOT_ID]` (via AWS CLI)
* **WARNING:** This will result in data loss since the snapshot. Confirm with client/team.
**Step 3.3: Deploy Previous Application Version (`v3.1.1`)**
* **Method A (Docker Compose - Single Instance):**
* `ssh ec2-user@your-ec2-instance`
* `cd /path/to/app`
* Edit `docker-compose.yml` to point to `v3.1.1` Docker image tags.
* `docker-compose down` (stops and removes current containers)
* `docker-compose pull` (pulls `v3.1.1` images)
* `docker-compose up -d --build` (starts `v3.1.1` containers)
* **Method B (AWS ECS/EKS):**
* Via AWS Console or AWS CLI: Update the ECS service to use the `v3.1.1` task definition/image tag.
* Monitor the deployment status.
* **Method C (Manual - Nginx/App Server):**
* If not using Docker, deploy `v3.1.1` code from your source control (e.g., `git checkout v3.1.1 && git pull`).
* Restart Nginx: `sudo systemctl restart nginx`
* Restart Application Server: `sudo systemctl restart gunicorn` (or equivalent)
**Step 3.4: Verify Rollback Success**
* **Application Access:** Access the application URL, confirm `v3.1.1` is running.
* **Key Functionality:** Perform quick smoke tests on critical features.
* **Logs:** Check Nginx, application, and database logs for errors.
* **Metrics:** Monitor CPU, memory, error rates in CloudWatch.
**4. Post-Rollback Actions**
* **Re-enable Traffic:** If instances were removed from Load Balancer, add them back.
* **Inform Stakeholders:** Communicate successful rollback and service restoration.
* **Root Cause Analysis:** Schedule a post-mortem to identify and address the root cause of the `v3.1.2` failure.
* **Update Documentation:** Reflect the rollback in deployment logs and project documentation.
**5. Sign-off**
* **Rollback Completed By:** [Your Name]
* **Date & Time:** [YYYY-MM-DD HH:MM UTC]
* **Client Confirmed:** [Yes/No]