deployment and operations
Background Jobs
Background workers execute delayed work outside web requests. Deploy, restart, retry, timeout, and failed-job handling are operational responsibilities, not only application code details.
Run Workers As Their Own Process
- Run workers separately from web processes.
- Set retry, timeout, and failure policies.
- Restart workers after deployments when code changes.
Exercise Success, Failure, And Restart
- Queue a staging job.
- Observe success and failure.
- Exercise graceful worker restart.
Make Retries Bounded
- Workers can run stale code after deployment.
- Infinite retries amplify outages.
- Unmonitored failed jobs become lost work.
Worker Command Shape
php bin/console queue:work --queue=receipt-email --timeout=60 --max-attempts=3
Workers are ready when lifecycle and failure handling are visible. A deploy is incomplete if web requests use new code while long-running workers continue processing jobs with an old release.
Practice
Practice: Operate A Receipt Worker
Plan the staging checks for a receipt-email worker before and during a deployment.
Requirements
- Run workers separately from web processes.
- Set retry, timeout, and failure policies.
- Restart workers after deployments when code changes.
- Queue a staging job.
- Observe success and failure.
- Exercise graceful worker restart.
Show solution
Run the receipt worker separately from web traffic with explicit timeout, retry, and failed-job handling. Queue one successful job and one controlled failure in staging, then confirm that logs and failed-job records are visible.
Restart workers gracefully during deployment and process another job afterward. This proves that workers do not remain on stale application code.