У deployment pipeline дуже легко поставити notification занадто рано. Код уже завантажений на сервер, Git показує новий commit - і система повідомляє команду: реліз успішний.
Але після оновлення Git revision застосунок ще може впасти на composer install, frontend build, migrations, cache rebuild, restart queue workers або Reverb. Навіть якщо всі ці команди завершилися без помилки, реальний HTTP request ще може повертати 500.
Тому для мене release notification має означати не "код скопійований", а "нова версія пройшла фінальну перевірку працездатності".
git pull підтверджує лише один етап deployment
Команда Git відповідає лише на вузьке запитання: який revision зараз знаходиться у working tree.
Вона нічого не доводить про PHP dependencies, database schema, frontend assets, Laravel cache або background processes.
git fetch origingit reset --hard origin/main DEPLOYED_SHA="$(git rev-parse HEAD)" echo "Code updated to: $DEPLOYED_SHA"Після Git ще залишається критична частина
У нашому Laravel deployment після зміни revision ідуть кроки, кожен з яких може зробити нову версію непридатною до роботи:
- встановлення production Composer dependencies;
- frontend build;
- database migrations;
- storage link та інші filesystem checks;
- очищення і перебудова Laravel caches;
- restart queue workers;
- restart Reverb;
- перевірка process state;
- вихід із maintenance mode;
- фінальний HTTP health check.
Maintenance mode задає правильну межу
Під час критичної частини deployment користувач не повинен бачити напівоновлений застосунок. Тому сайт переходить у maintenance mode до зміни активного application code.
Якщо критичний крок падає, deployment не має "успішно" повідомляти про реліз. Потенційно пошкоджена версія залишається прихованою за контрольованою 503 сторінкою до recovery або rollback.
Start deployment |Enable maintenance |Update code |Install dependencies |Build assets |Run migrations |Rebuild caches |Restart workers / Reverb |Command success ще не дорівнює application health
Pipeline може побачити exit code 0 від Composer, migrations і cache commands. Це корисні сигнали, але вони перевіряють лише свої операції.
Фінальний application-level check повинен пройти після всіх deployment steps, коли користувацький traffic знову може потрапити в нову версію.
curl \ --fail \ --silent \ --show-error \ --max-time 10 \ https://example.com/health \ > /dev/nullHealth check має перевіряти більше, ніж Nginx
Відповідь 200 від статичного файлу доводить, що Nginx працює, але не обов’язково доводить, що Laravel може завантажитися.
У deployment closeout корисно окремо мати сигнали про Laravel boot, database connection, frontend assets, queue workers і Reverb. Фінальний HTTP request доповнює ці перевірки як останній gate.
Success notification має бути після gate
Найпростіше правило: success notification є side effect успішного deployment outcome, а не side effect Git command.
Тобто спочатку pipeline проходить усі перевірки, фіксує deployed SHA і лише потім створює release notification.
DEPLOYED_SHA="$(git rev-parse HEAD)" run_deployment_stepsverify_supervisor_processesverify_reverbdisable_maintenance_moderun_final_health_check notify_release_success "$DEPLOYED_SHA"Failed health check не повинен створювати success notification
Якщо фінальний health check падає, у нашій deployment моделі maintenance mode активується знову, а job завершується помилкою.
У цей момент можна створити окремий deployment failed alert, але не success release notification. Це різні події з різною семантикою.
if ! run_final_health_check; then enable_maintenance_mode notify_deployment_failed "$DEPLOYED_SHA" exit 1fi notify_release_success "$DEPLOYED_SHA"Deployed SHA варто включати в notification
Release notification стає значно кориснішою, якщо містить immutable reference на реально розгорнутий commit.
Тоді повідомлення відповідає не лише на "реліз завершився", а й на "яка саме версія зараз пройшла health check". Це спрощує rollback, incident analysis і звірку з pipeline.
Release successful Commit: abc1234Environment: productionHealth check: passedWorkers: runningRealtime: runningНе надсилайте notification до commit deployment state
Якщо система окремо зберігає deployment record або deployed SHA, спочатку потрібно зафіксувати успішний outcome, а потім створювати notification.
Так notification не стане єдиним доказом того, що реліз був успішним. Вона лише повідомляє про вже зафіксований deployment state.
Що тестувати
- Git update успішний, але Composer падає - success notification відсутня;
- migrations падають - success notification відсутня;
- queue worker або Reverb не RUNNING - success notification відсутня;
- final HTTP health check повертає помилку - maintenance повертається, job failed;
- усі deployment steps і health check PASS - рівно одна success notification;
- retry deployment не створює дубль notification для того самого successful deployment outcome;
- notification містить deployed commit SHA, який відповідає фактичному release.
Release notification повинна повідомляти про перевірений стан застосунку, а не про завершення однієї команди всередині deployment.
Підсумок
git pull, fetch/reset або checkout нового commit - лише початок deployment, а не доказ успішного релізу.
Success boundary має бути після dependencies, assets, migrations, caches, background processes, виходу з maintenance і фінального application health check.
Лише після цього release notification чесно означає те, що читає користувач або команда: нова версія справді розгорнута і перевірена.
