Make the release procedure executable Continuous delivery for a Laravel application on a VPS means turning a known deployment checklist into a controlled w...
Make the release procedure executable
Continuous delivery for a Laravel application on a VPS means turning a known deployment checklist into a controlled workflow. The workflow should test the exact commit, build artifacts from locked dependencies, transfer or activate a release, run approved migrations, and verify application health. A green CI badge only proves the tests passed; it does not prove the deployed system works.
Begin with the existing manual deployment steps. If those steps are unclear or contain destructive cleanup, document and test them before automating. Identify the deployment user, application directory, shared storage, process manager, and rollback mechanism.
Separate build and deployment
The build job can install Composer dependencies, run focused tests, compile frontend assets, and package a release. Pin action versions and dependency lockfiles. The deployment job should consume that artifact instead of running a fresh uncontrolled dependency resolution on the server.
Use a protected GitHub Actions environment for production. Environment approvals and secrets can restrict which branches deploy and who can start a production release. Grant the workflow only the repository permissions it needs, and use a dedicated deployment credential rather than a personal administrator key.
Preserve persistent state
User uploads, environment secrets, logs, and cache data are not release artifacts. Keep them in shared locations or managed services and connect the new release to them. Confirm that public/storage is the intended link before changing it. A broad deletion command in a release script can destroy real uploads when a symlink is absent.
Database migrations should be reviewed for compatibility with the currently running release. When zero downtime matters, add new columns first, deploy code that can read old and new shapes, then remove old fields in a later release.
Sequence the production steps
Record the commit and current release, verify the backup, activate the new artifact, run the reviewed migration once, refresh application caches, and restart long running queue workers. Probe an authenticated and public route, an image, and a representative background job. If the probe fails, return traffic to the prior code release while deciding whether the schema change needs a forward fix.
For shared hosting without atomic symlinks, the same principles apply, but the deployment may require a maintenance window. State that expected downtime in the runbook.
Test the workflow
Use a staging environment with similar PHP extensions, database engine, and queue configuration. Test a failed migration, missing secret, bad asset build, worker restart, and rollback. Audit logs should identify which commit and operator initiated a release.
Common mistakes
- Storing a production SSH private key in repository files.
- Running tests on one commit and deploying another.
- Treating a successful file transfer as a successful release.
- Forgetting queue workers still run old code.
- Automatically executing seeders that rewrite customer content.
Conclusion
A useful CI/CD pipeline makes a reviewed release reproducible and observable. It should make failure and rollback as explicit as the happy path. Our cloud and DevOps solutions cover that operating model.
References