如何为Laravel配置CircleCI迁移、种子文件及测试数据库CI方案？

Hey there! Let's walk through how to set up your Laravel migrations/seeders for CircleCI, plus break down the pros and cons of your two test database options to help you pick the right fit.

一、CircleCI基础配置（适配迁移与种子） #

First, you'll need a .circleci/config.yml file in your project root to define the CI workflow. Here's a practical template that covers dependency installation, database setup, and running your migrations/seeders:

version: 2.1
jobs:
  build:
    docker:
      # Use a PHP image matching your Laravel version
      - image: cimg/php:8.2-node
      # Spin up a test database (swap with postgres:15 if you use PostgreSQL)
      - image: cimg/mysql:8.0
        environment:
          MYSQL_ROOT_PASSWORD: root
          MYSQL_DATABASE: laravel_test
    steps:
      - checkout
      - run:
          name: Install Composer dependencies
          command: composer install --no-interaction --prefer-dist
      - run:
          name: Set up environment file
          command: cp .env.example .env
      - run:
          name: Generate app key
          command: php artisan key:generate
      - run:
          name: Configure test database credentials
          command: |
            sed -i 's/DB_DATABASE=.*/DB_DATABASE=laravel_test/' .env
            sed -i 's/DB_USERNAME=.*/DB_USERNAME=root/' .env
            sed -i 's/DB_PASSWORD=.*/DB_PASSWORD=root/' .env
      # Pick ONE of the following blocks based on your chosen database strategy
      # --- Option 1: Run all migrations ---
      - run:
          name: Execute database migrations
          command: php artisan migrate --force
      # --- Option 2: Import SQL structure + run seeders ---
      # - run:
      #     name: Import base database structure
      #     command: mysql -h 127.0.0.1 -u root -proot laravel_test < database/structure.sql
      - run:
          name: Run database seeders
          command: php artisan db:seed --force
      - run:
          name: Execute tests
          command: php artisan test

二、Your Two Test Database Options: Pros, Cons & Recommendations #

Option 1: Run Migrations From Scratch #

What's good about it:

• It mirrors your production database deployment flow exactly. This means you'll catch migration bugs (like syntax errors, dependency issues) before they hit production.
• No extra files to maintain—your migration files are the single source of truth for database structure.

What's tricky:

• If you've got dozens of migrations (especially complex legacy ones), this will slow down your CI runs significantly. Waiting 5+ minutes for migrations every time you push code kills iteration speed.
• Legacy migrations that rely on external systems or old data might fail in the isolated CI environment.

Pro tips to fix the pain points:

• Consolidate old migrations: Bundle your earliest 10+ migrations into a single "base structure" migration. For example, create 20240101000000_create_core_tables.php that defines all your initial tables, then delete the old individual migrations. This cuts down CI run time drastically.
• Skip problematic legacy steps: Add conditional logic to legacy migrations so they skip external dependencies when running in CI. For example:

  if (!app()->environment('testing')) {
      // Run the legacy external data import only in non-CI environments
      $this->importLegacyData();
  }
  

Option 2: Import SQL Structure + Seeders #

What's good about it:

• It's blazingly fast. Importing a pre-built SQL file is way quicker than running 50+ migrations—your CI runs will finish in a fraction of the time.
• Perfect if your legacy migrations are too messy to run reliably in CI.

What's tricky:

• You have to manually keep the SQL file in sync with your migrations. If someone adds a new migration but forgets to update the SQL file, your CI database will be out of date, leading to false test failures.
• You won't catch migration bugs until you deploy to production, since you're not actually running the migration files in CI.

Pro tips to avoid headaches:

• Automate SQL file generation: Add an Artisan command or Git pre-commit hook that auto-generates the structure.sql file after running migrations locally. For MySQL, this would look like:

  mysqldump -u root -p --no-data laravel > database/structure.sql
  

  Commit this file alongside your migrations to ensure it's always up to date.
• Validate periodically: Every few weeks, run a full migration sequence locally, then compare the generated SQL structure to your saved file. This catches any drift before it causes problems.

三、Seeder Best Practices for CI #

• Keep seeders lean: Only include essential test data (like default roles, system configs). Avoid seeding thousands of rows—this slows down CI.
• Use environment-specific seeders: Create a TestSeeder that only runs in CI, with data tailored for your test suite. Call it explicitly in your config:

  php artisan db:seed --class=TestSeeder --force
  

• Always use --force: This skips the production environment warning, so CI can run seeders automatically without user input.

内容的提问来源于stack exchange，提问作者oscar.rpr