Deployment with
symlink releases.

A symlink is a link that points to a folder, like a shortcut on your computer’s desktop: open it and you’re in the folder it points to. In general, it works like this:

• Each version of the website has its own folder.
• One link says which version is live.
• Uploaded files and settings stay aside, outside the individual versions.

Switching the live site to another version then means repointing just one link.

• Website files aren’t uploaded in pieces: the new version is fully ready before the live site switches to it.
• We restore the website code to the previous version within 5 minutes, because we only switch the link back.
• Preparation and checks happen off the live site, while visitors keep seeing the original version.

We deploy through GitLab CI/CD, an automated process that tests a code change and hands it over for deployment. Like a quality-control line, it runs every change through the same checks before it goes live. We prepare the new version off the live site, and the deployment itself has four steps.

1. Backup before deployment. Before anything switches, we save a database backup.
2. Version switch. The live site switches to the new version in one step.
3. Smoke test. A quick check that the site is up and key URLs work, like a lighting check before opening night.
4. Restoring the previous version. If the new version fails, we restore the website code to the previous version within 5 minutes.

The 5-minute limit covers the website code, not the database, because the two are restored separately.

• Every code change goes through version control (a logbook of who changed what, with the option to go back) and a new deployment.
• We back up the database every night and keep backups for 14 days. We test restoring from a backup at least once a quarter.