Capstone Deployment Sprint: Full Production Release

Capstone Deployment Sprint: Full Production Release

This lab is your final, independent demonstration that you can take a real web application from source code to a live, secure, monitored production environment. You will work alone, applying every skill from this course: server hardening, TLS, CI/CD pipelines, secrets management, and operational monitoring. A graded runbook ties everything together.

What the Sprint Requires

You will receive a sprint application package — a Python Flask or PHP application that connects to a database. Your job is to deploy it fully and professionally. That means:

• A hardened VPS with only necessary ports open and SSH key authentication enforced
• A valid HTTPS certificate (typically issued by Let's Encrypt via Certbot)
• A working CI/CD pipeline that runs automated tests and deploys on a successful push
• Secrets (database passwords, API keys) stored outside source control
• Log monitoring so you can observe the running application
• A completed deployment runbook a colleague could follow

Phase 1: Pre-Deployment Planning

Before you touch a terminal, complete the written pre-deployment checklist. This is not busywork — skipping planning is how production outages start.

Your checklist must confirm:

• Server state: Is the VPS updated? Are unnecessary services stopped? Is the firewall (`ufw` or `firewalld`) configured to allow only ports 22, 80, and 443?
• DNS: Does your domain or subdomain A-record resolve to the VPS IP? (Allow time for propagation.)
• TLS: Is Certbot installed and is port 80 temporarily accessible for the ACME HTTP-01 challenge?
• Environment variables: Have you identified every secret the application needs, and have you planned where to store them (`.env` file excluded from git, systemd `EnvironmentFile`, or a secrets manager)?
• Pipeline configuration: Is your GitHub Actions (or equivalent) workflow file written and do the runner's environment secrets match the names the application expects?

Writing this checklist forces you to catch problems before they appear mid-deployment.

Phase 2: Executing the Deployment

Work through the deployment in a logical order to avoid circular dependencies.

1. Push code to GitHub. Confirm your `.gitignore` excludes `.env`, credential files, and any private keys. Run `git log` and inspect the repository on GitHub to verify no secrets appear in any commit.

2. Trigger the CI/CD pipeline. The pipeline must run tests first. If tests fail, the deployment step must not run. Inspect the Actions log (or equivalent) to confirm the sequence.

3. Confirm deployment to VPS. SSH in and verify the application process is running (`systemctl status` or `docker ps`). Check the application log for startup errors.

4. Verify HTTPS. Open the HTTPS URL in a browser and confirm the padlock and a valid certificate. Use `curl -I https://yourdomain.example` to see the response headers and confirm no HTTP-to-HTTPS redirect is missing.

5. Verify secrets are not in source control. On GitHub, search your repository for any known secret string. Confirm it returns no results.

Phase 3: The 10-Minute Instructor Walkthrough

You will present the live deployment to your instructor. Structure your ten minutes:

• 2 minutes: Show the GitHub repository — point out `.gitignore`, the workflow file, and confirm no secrets are visible.
• 3 minutes: Trigger a fresh pipeline run (push a trivial commit or re-run the last job). Walk through the CI log showing tests pass, then deployment runs.
• 2 minutes: Open the HTTPS URL, show the certificate details, demonstrate the application works end-to-end.
• 2 minutes: Show log output in real time (e.g., `journalctl -u yourapp -f` or a Docker log tail). Make one HTTP request and show it appear in the log.
• 1 minute: Explain your rollback procedure — how would you revert to the previous working version?

Completing the Runbook

The runbook is a graded deliverable. It must be clear enough that a colleague who did not build this deployment can operate it. Required sections:

• Architecture overview (server, domain, database, application server)
• Step-by-step deployment procedure
• How secrets are managed and rotated
• Monitoring approach and how to read the logs
• Rollback procedure with exact commands
• Known issues or limitations

Write in plain prose with numbered steps where sequence matters. Paste exact commands with placeholders for values that vary by environment.

Safety and Security Reminders

In web deployment, "safety" means preventing unauthorized access and data loss.

• Never commit secrets. Rotate any credential that touches a git repository, even briefly.
• Firewall before certificate. Confirm the firewall rules are correct before exposing port 443.
• Least privilege. The application process should run as a non-root system user with access only to the files and ports it needs.
• Backup before changes. Before any production change, note the current working state so rollback is straightforward.
• Validate TLS. A self-signed certificate is not acceptable for production; it trains users to ignore browser warnings.

Grading Rubric Summary

Six criteria are scored, and you need 80% overall with no single criterion below 60%:

| Criterion | What is evaluated |

|---|---|

| Server hardening | Firewall, SSH config, no root login |

| HTTPS | Valid certificate, redirect from HTTP |

| CI/CD pipeline | Tests run, deploys only on pass |

| Secrets management | No secrets in source control or logs |

| Monitoring | Log access demonstrated live |

| Runbook quality | Complete, accurate, usable by a peer |

Review the full rubric before you begin so you know exactly what each criterion demands.