Laravel: деплой і продакшен

Деплой без простою: користувачі весь час бачать робочу версію.

Atomic (symlink) deploy - кожен реліз клонується в нову папку, там встановлюються залежності й збираються ассети, після чого current атомарно перемикається через symlink:

releases/2026_06_05_120000/ ← новий
current → releases/... ← атомарне перемикання

Кроки на деплої: composer install --no-dev, npm run build, migrate --force, кеш конфіг/маршрутів, перезапуск воркерів (queue:restart) і OPcache.

Інструменти: Envoyer, Deployer, CI/CD-пайплайни, Kubernetes (rolling update). Окрема увага - сумісність міграцій із попередньою версією коду під час перемикання.

Докладніше в документації: Деплой

Файл .env лежить у корені проєкту й зберігає налаштування, специфічні для середовища, та секрети: доступи до БД, API-ключі, APP_KEY, режим APP_ENV. Ідея в тому, що той самий код працює в різних середовищах (локально, staging, продакшен) лише завдяки різним .env.

APP_ENV=local
APP_DEBUG=true
DB_CONNECTION=mysql
DB_PASSWORD=secret
STRIPE_KEY=sk_test_...

Ключові правила:

• .env не комітиться в git (він у .gitignore) - кожен розробник і сервер має власний. Натомість комітять .env.example як шаблон без секретів.
• Значення зчитуються хелпером env('KEY', 'default'), але викликати env() слід лише у файлах config/.
• У застосунку звертайтесь через config('services.stripe.key'), а не env(...) напряму: після php artisan config:cache (оптимізація на проді) виклики env() поза конфігом повертають null.

Навіщо: секрети не потрапляють у код/репозиторій, а конфігурацію легко змінювати під середовище без редагування коду.

Докладніше в документації: Конфігурація

CI автоматично перевіряє кожен пуш, CD - автоматично доставляє код.

Типовий пайплайн (GitHub Actions / GitLab CI):

- composer install
- vendor/bin/pint --test # стиль
- vendor/bin/phpstan analyse # статичний аналіз
- php artisan test --parallel # тести
- npm ci && npm run build # ассети
# → деплой при успіху

Деплой: SSH-скрипт, Docker-образ у реєстрі + rolling update у Kubernetes, або сервіси на кшталт Forge/Envoyer. На етапі деплою - migrate --force, кешування конфіга/маршрутів, queue:restart. CI/CD дає швидкий зворотний зв'язок і знижує ризик людської помилки при релізі.

Докладніше в документації: Деплой

Головний ризик - несумісність схеми зі старим кодом під час деплою та блокування таблиць.

Безпечні зміни (expand → migrate → contract):

1. Додати нову колонку (nullable) - старий код працює.
2. Задеплоїти код, що пише і в стару, і в нову.
3. Перенести дані (фоновий job), перемкнути читання.
4. Окремим релізом видалити стару колонку.

Практики:

• Не покладатися на migrate:rollback у проді - down() може втрачати дані. Краще forward-fix.
• Великі ALTER на величезних таблицях блокують → онлайн-міграції (pt-online-schema-change, gh-ost).
• php artisan migrate --force у пайплайні; --isolated, щоб не виконати паралельно на кількох воркерах.
• Бекап перед руйнівними операціями; прогін міграцій на staging.

Докладніше в документації: Міграції

Підключення оголошуються в config/database.php. Вибір конкретного:

DB::connection('reporting')->table('events')->get();

class AnalyticsEvent extends Model
{
    protected $connection = 'reporting'; // модель завжди на цьому з'єднанні
}

Типові сценарії:

• Read/Write splitting - окремі хости для читання й запису (Laravel сам маршрутизує SELECT на репліку):

  'mysql' => ['read' => [...], 'write' => [...]],
  

• Окрема аналітична або legacy-БД.

Докладніше в документації: Кілька підключень до БД