Final Tool Choices & Why We Used Them
Stores your website's code, including Jenkinsfile, Dockerfile, and source files.
Triggers Jenkins pipelines on code push (e.g., to main branch).
2. Jenkins → Automation
Automates the CI/CD process.
Pulls code from GitHub, builds Docker image, deploys to EC2, and runs tests.
3. Docker → Packaging & Deployment
Creates a container image for your app.
Ensures the app runs the same in any environment (local, EC2, etc.).
4. AWS EC2 → Hosting
Provides a virtual server to run Jenkins and Docker containers.
Hosts the live application accessible via a public IP.
5. Nginx → Web Server
Serves the built front-end app from the Docker container.
Handles incoming HTTP traffic on port 80.
GitHub Actions vs Jenkins
Jenkins offers high customization but is resource-heavy and requires a dedicated server.
GitHub Actions is built-in and simpler for smaller projects but needs YAML workflow knowledge.
We used a basic git pull approach from EC2 to keep things simple and manageable.
Docker vs Manual Flask Deployment
Docker provides containerization and easy replication but had repeated setup issues on EC2.
Manual Flask setup with gunicorn and nginx was more stable and faster to implement.
Route 53 vs DuckDNS
Route 53 is professional but paid.
DuckDNS is free and perfect for students dealing with EC2’s changing IP.
CI Tools vs Git Pull
Full CI tools automate everything but require setup time and learning.
Manual/triggered git pull offered enough control with minimal complexity.
I realized that tool selection is all about choosing what works best for the project — not just the most popular or complex solution. We prioritized free, reliable, and easy-to-integrate tools. Even without Docker or Jenkins, we built a complete working DevOps flow for our AI-based web app. This phase helped us think critically about technical trade-offs and reinforced that simplicity often leads to better stability.