GitHub Actions for Your Portfolio: How to Set Up CI/CD That Runs Tests and Deploys on Every Push
The single file that most differentiates a student portfolio from a professional one is .github/workflows/deploy.yml. Its presence tells the recruiter that your project has automated testing and deployment — that you did not just write code and upload it, you built a pipeline that verifies and ships it. Its absence tells the recruiter nothing because 95% of student portfolios do not have CI/CD. Adding this file takes 30 minutes. It is the highest-signal 30-minute investment you can make in your GitHub profile.
A complete GitHub Actions workflow for a portfolio project has four stages: (1) Install dependencies and run linting, (2) Run unit and integration tests, (3) Build a Docker image, and (4) Deploy to your VPS via SSH. Stages 1–3 run on every push and every pull request. Stage 4 runs only on push to the main branch. Each stage depends on the previous stage: if tests fail, the build does not run. If the build fails, the deploy does not run. This is the CI/CD pattern that professional teams use, and implementing it in a student project demonstrates that you understand deployment as an engineering discipline, not a manual process.
The Workflow File Structure
A minimal but complete workflow file defines: a trigger (push to main and pull requests to main), a job called "test-and-deploy" running on ubuntu-latest, a services block that starts Postgres and Redis as Docker containers (your tests need a real database), steps that checkout code, set up Node.js, install dependencies, run linting, run tests with DATABASE_URL pointing to the service container, build a Docker image if tests pass, and SSH into your VPS to pull and restart the application if pushing to main. The file is approximately 60 lines. Every line serves a specific purpose. Recruiters who see this file in your repository know you have operated a CI/CD pipeline. That knowledge translates directly to reduced onboarding time, which translates directly to interview priority.
Why CI/CD Matters More Than the Code It Tests
The paradox of junior engineering portfolios is that the code quality is rarely what gets you hired. The infrastructure around the code — the tests, the deployment pipeline, the monitoring — is what signals professional readiness. A recruiter cannot evaluate the quality of 500 lines of Express routes in 30 seconds. They can evaluate the presence of a GitHub Actions workflow, a passing test badge, and a Dockerfile in under 10 seconds. These are the signals that determine whether the recruiter spends the remaining 20 seconds reading your code or moves to the next resume. Build the signals first. The code quality will be evaluated in the interview. The signals get you the interview.
Copy a GitHub Actions workflow template. Modify the Node version and service containers to match your stack. Commit and push. Watch the Actions tab in your GitHub repo as the pipeline runs. When it passes (green checkmark), add a status badge to your README. The badge is visible proof that your code passes automated tests. No amount of README description communicates "this code works" as clearly as a green badge that is generated by an automated system. Total time: 30 minutes. Recruiter impact: significant.