Building an automated
CI/CD pipeline for my portfolio

Push code → site updates itself

Manually copying files to a server and restarting it is slow and error-prone. I wanted the professional workflow: commit my changes, and have the live site update automatically — with a safety gate so not every push goes out.

The pipeline, stage by stage

The parts that made it solid

Getting a deploy to run is easy. Getting it to run securely and reliably is where the real engineering is. These are the pieces I'm proudest of.

Spotlight: "escaping the terminal" with sudoers

When you run sudo by hand, Linux can pop up a password prompt because you have a terminal. Jenkins runs commands non-interactively — there is no terminal — so sudo fails with "a terminal is required to authenticate." The fix isn't to fake a terminal; it's to remove the need to authenticate at all, but only for the exact commands the deploy needs:

jenkins ALL=(ALL) NOPASSWD: /usr/bin/rsync, /usr/bin/systemctl restart apache2

The Jenkinsfile

The whole pipeline is defined as code and version-controlled with the site itself — two stages: the safety gate, then the deploy.

pipeline {
    agent any
    stages {

        // Note: before these stages run, Jenkins auto-checks-out (clones)
        // the repo from GitHub over SSH — that's how it gets this Jenkinsfile.

        // 1 — only deploy when the commit message says so (repo is already cloned)
        stage('Check Commit Message') {
            steps {
                script {
                    def msg = sh(script: 'git log -1 --pretty=%B',
                                 returnStdout: true).trim()
                    echo "Latest commit: ${msg}"
                    if (!msg.toLowerCase().contains('deploy')) {
                        error "Commit must contain 'deploy' to ship."
                    }
                }
            }
        }

        // 2 — ship it over SSH
        stage('Deploy') {
            steps {
                sshagent(credentials: ['Jenkin-myportfolio-aws']) {
                    sh '''
                        ssh -o StrictHostKeyChecking=no jenkins@<server> '
                            cd ~/MyPortfolio &&
                            git pull origin main &&
                            sudo rsync -a --delete ~/MyPortfolio/ /var/www/html/ &&
                            sudo systemctl restart apache2
                        '
                    '''
                }
            }
        }
    }
}

Real errors, and how I debugged them

It didn't work first try — and that's the interesting part. Each error taught me something about how these systems actually fit together.

What I ended up with

What I took away

• ✓CI/CD is a chain of trust. GitHub → Jenkins → server each needs its own authentication, and the pipeline is only as reliable as its weakest link.
• ✓Non-interactive ≠ interactive. "It works when I run it myself" hides a lot — different user, terminal, and cached credentials. Always test the way the machine actually runs it.
• ✓Least privilege is practical, not just theory. Scoping sudo and using a dedicated deploy user made the system both safer and easier to reason about.
• ✓Reading the error message is the skill. Each failure named exactly what was wrong once I learned to interpret it — firewall vs. auth vs. permissions.