CI/CD with GitHub Actions

Automated deployment with GitHub Actions

Deploying a site by hand over FTP is a source of errors: a file forgotten, the wrong version uploaded, a configuration overwritten. Automation removes the human factor and makes rollback predictable.

What I set up

• automatic deployment when a branch is updated;
• separate branches for staging and production;
• pre-flight checks: syntax, and tests where they exist;
• exclusions for what must never reach the server: configuration, cache, user uploads;
• post-deploy steps: cache clearing, migrations, service restarts;
• result notifications;
• a mechanism for rolling back to the previous version.

The hard part is not the automation

Technically, setting up a pipeline is straightforward. The harder part is separating code from data. In a typical site, one directory holds both the files that should be deployed and the things users create: uploaded images, cache, logs. Without that separation, automated deployment wipes user data.

So the work usually starts with tidying the structure rather than with writing the pipeline.

Who this makes sense for

Projects where changes ship regularly and a staging environment exists. If the site is updated twice a year, automation will not pay for itself — a proper backup before changes is enough.