🛠 Project: Deploy with Rollback

Copying a new version of a website over the old one is risky. For a moment visitors see half of each, and if the new version is broken there's no going back. Real deployments do it differently:

/var/www/releases/v1/   ← each version in a folder of its own, never changed
/var/www/releases/v2/
/var/www/current  →  /var/www/releases/v1    ← nginx serves this link

Going live means switching a link, which happens in an instant. Going back means switching it again. nginx's site http://app.test already serves /var/www/current, and versions 2 and 3 are waiting in ~/releases.

What to build

1. ~/scripts/deploy.sh VERSION unpacks ~/releases/site-VERSION.tar.gz into /var/www/releases/VERSION and points /var/www/current at it
2. ~/scripts/rollback.sh VERSION points /var/www/current back at an older version
3. Finally: deploy.sh must refuse a release without an index.html, so a broken version never goes live

Building blocks

readlink /var/www/current                          # Which version is live?
ln -sfn /var/www/releases/v2 /var/www/current      # Point the link elsewhere (-f replace, -n the link itself)
mkdir -p /var/www/releases/v2
tar -xzf /home/student/releases/site-v2.tar.gz -C /var/www/releases/v2
[ -f /var/www/releases/v3/index.html ]             # Is the page there?
curl -s http://app.test | grep '<p>'               # What do visitors see?

💡 The scripts run with sudo (/var/www is root's), and under sudo ~ is root's home, /root. So write the path to the releases in full: /home/student/releases.