Думки, досвід і рішення про розробку та не тільки.
Парольний вхід і Google OAuth можуть давати різні гарантії щодо email, тому одна перевірка після входу не завжди правильна. Розбираю, коли локальне підтвердження email потрібне, коли його можна не дублювати і чому вимкнене підтвердження email не повинно випадково блокувати OAuth-користувачів.
SSH може перестати приймати нові підключення, хоча сервер доступний, сайт працює, а sshd активний. Одна з неочевидних причин - автоматичні тунелі, які після розриву з’єднання перепідключаються занадто часто й потрапляють під UFW LIMIT.
Одна платформа може вже показувати нове Open Graph-зображення, а інша ще тримати старий попередній перегляд. Це не завжди означає помилку в meta tags. Перевіряти потрібно окремо HTML, SSR, доступність og:image, HTTP-відповідь і кеш конкретного робота.
Відсутнє джерело переходу не завжди означає втрату даних. Прямий вхід, скопійоване посилання, месенджер, мобільний застосунок або видалений Referer можуть чесно залишити джерело невідомим. Головне - відрізняти об’єктивно невідоме походження від помилки власного відстеження.
Порада
Коли на одній машині живе кілька Docker-проєктів, оновлення PHP має залишатися локальною зміною конкретного середовища. Ізольований runtime, окремі workspace-контейнери, зрозумілі імена сервісів і перевірка Composer-сумісності допомагають не перетворити оновлення одного проєкту на приховану поломку іншого.
Успішно виконані команди розгортання ще не доводять, що застосунок працює. Після переключення потрібно перевірити HTTP-відповідь, критичні сервіси та фонові процеси, а при помилці - відкотити версію й перевірити вже результат відкату.
Якщо збірка, залежності, конфігурація або базові перевірки можуть впасти ще до зміни production стану, немає сенсу спочатку робити сайт недоступним. Режим обслуговування варто вмикати лише після попередніх перевірок, коли залишилися кроки, які справді потребують короткого вікна недоступності.
Якщо сторінка адмінки лише показує фактичний стан налаштувань, а різні групи зберігаються в одній таблиці, завантаження всіх Settings-класів може бути зайвим. Для режиму лише читання інколи простіше й точніше прочитати таблицю напряму, не перетворюючи цей підхід на обхід правил запису.
WebSocket добре підходить для миттєвого оновлення інтерфейсу, але подія може бути пропущена. Вкладка могла спати, мережа могла зникнути, ноутбук - прокинутися після паузи. Тому оперативні події варто поєднувати з HTTP-оновленням, яке відновлює фактичний стан.
Скрипт, який запускається один раз, все одно може створити дублікати, записати дані не в ту категорію, опублікувати внутрішні службові позначення або зламати двомовну структуру. Якщо він змінює production дані, його варто захищати так само серйозно, як звичайний код застосунку.
Порада