Pipeline setup
GitHub Actions or GitLab CI running linting, tests and build on every push, with branch protection so unreviewed code cannot reach production.
Servers, Hosting & DevOps
DevOps & CI/CD
The point of a deployment pipeline is not speed, it is repeatability. When every release runs the same automated steps in the same order, the question "what was different about this deploy?" has an answer, and rolling back is a decision rather than an adventure.
I build pipelines that are proportionate. A small business site does not need Kubernetes; it needs tests that run on every push, a build artefact, an atomic deploy and a one-command rollback.
How I work on it
Process
Adjusted to the job, but this is the shape it usually takes.
-
Automate the current process first
Whatever the manual deploy steps are, they get scripted before they get improved. Automating a bad process still removes the human error.
-
Add the safety net
Tests in CI and a rollback path, before speeding anything up.
-
Make environments match
Same OS, same runtime versions, same extensions. Most "only breaks in production" bugs are environment drift.
-
Document the failure path
How to roll back, who has access, and what to check first, written down before it is needed at 2am.
Questions
Things people ask
Not always. Docker pays off when environments drift, when there are several services, or when developers run different operating systems. For a single PHP application on one server that has been stable for years, it can be added complexity for little return.
Almost certainly not, unless you have a platform team to run it. For most sites it is far more operational burden than the problem justifies. A well-configured single server or a small managed platform covers a lot of ground.
They run as an explicit pipeline step, and they are written to be backward compatible, add columns before code uses them, remove them a release later. That way a rollback of the code does not require a rollback of the schema.