Запуск seeders із migrations: як автоматизувати наповнення бази даних у Laravel

Laravel seeders — це інструмент для наповнення бази даних. Зазвичай вони містять два типи даних:

• Критичні дані для роботи застосунку (ролі, категорії, налаштування за замовчуванням), що мають бути на локальному середовищі, стейджингу та production.
• Тестові (dummy) дані для локальної розробки, яким не місце на production.

Використовувати SSH для запуску php artisan db:seed цілком прийнятно, поки ваш проєкт ще не запущено. Проте після виходу в live з реальними користувачами ручний запуск seeders стає слабкою ланкою в процесі деплою.

Випадкова помилка у назві seeder може призвести до появи некоректних даних або, що гірше, перезаписати реальні дані. Якщо ви використовуєте zero-downtime deployment, а нова функція залежить від засиджених даних, застосунок може бути недоступним у проміжку між завершенням деплою та ручним запуском команди Artisan. У разі помилки під час сидингу вам доведеться відкочувати все вручну.

Скрипт деплою вже автоматично запускає migrations. Наповнюючи базу безпосередньо через міграції, ви точно знаєте, що і коли виконається. Якщо щось піде не так, migration видасть помилку, а деплой зупиниться.

Для невеликих наборів даних це виглядає просто:

return new class extends Migration
{
    public function up(): void
    {
        Schema::create('cities', function (Blueprint $table) {
            $table->id();
            $table->string('name');
            $table->string('country_code');
            $table->timestamps();
        });

        DB::table('cities')->insert([
            ['name' => 'Brussels', 'country_code' => 'BE'],
            ['name' => 'Antwerp', 'country_code' => 'BE'],
            ['name' => 'Ghent', 'country_code' => 'BE'],
        ]);
    }
};

Для великих масивів даних ми часто використовуємо CSV або JSON-файли, які migration зчитує та імпортує в базу.

Міграції мають залишатися детермінованими

Migrations мають часову мітку та принцип «тільки додавання» (append-only), що підкреслює: їх не можна змінювати після запуску. Результат виконання міграції сьогодні має бути ідентичним результату через місяць.

Seeders такої гарантії не дають — вони змінюються з часом. Якщо migration залежить від seeder, хтось може випадково змінити останній, що вплине на роботу міграції. Те саме стосується factories, які еволюціонують разом із проєктом.

Саме тому в міграціях краще використовувати DB::table() замість Eloquent-моделей. Моделі змінюються (нові casts, observers, accessors), що може спричинити побічні ефекти, яких не було на момент написання міграції. Натомість DB::table() — це пряма та передбачувана операція з базою даних.

Стейджинг працює інакше

На staging-серверах деплой часто передбачає повне очищення бази. Тут запуск php artisan migrate:fresh --seed є доречним, оскільки немає ризику пошкодити реальні дані.

Швидкість понад усе

Seeders — чудовий інструмент для локальної розробки та тестів. Чим швидше вони працюють, тим швидше ви розгортаєте середовище, запускаєте тести та завершуєте деплой.

Бажаєте швидких результатів? Скористайтеся допомогою Claude або іншого ШІ-агента для аудиту та бенчмаркінгу ваших seeders. Оптимізація сидингу з декількох хвилин до секунд суттєво покращить developer experience вашого проєкту.