FTP is not deployment
Copying files to a live server means partial states where some files are new and some are old, no record of what changed, and no way back except copying older files over the top.
Every production incident we have been called into that started with “we just uploaded a fix” would have been prevented by a proper deployment process.
What a process needs
- Code in version control, deployed from a specific commit
- Dependencies installed as part of deployment, not uploaded
- Database migrations run in a controlled order
- Atomic switch so the site never serves a half-deployed state
- A tested rollback, not a theoretical one
Environments that match
- Same PHP version as production
- Same database engine and version
- Same extensions enabled
- Configuration through environment variables, not edited files
- Test data that resembles production in shape, not in content
“It worked on staging” is only useful if staging resembles production. Different PHP versions between the two makes the staging environment nearly worthless.
Database migrations need care
Schema changes are the part of deployment that cannot easily be rolled back. Design them to be backwards compatible where possible: add columns before using them, remove them in a later deployment.
That discipline means a rollback of code does not require a rollback of the database, which is what makes rollback practical.
Secrets belong in the environment
| Never | Instead |
|---|---|
| Credentials in the repository | Environment variables |
| Production keys on developer machines | Separate credentials per environment |
| Config edited on the server | Config from the environment |
| Shared logins | Individual accounts with audit |