第14回: マイグレーション管理 — DBスキーマの変更を「チームで安全に展開」する

(Updated: )
1 min read

章: 第2章: データベース応用

「ローカルでは動いたのに本番で動かない」——DBの差異が原因

開発者Aが users テーブルに phone カラムを手動で追加したが、開発者Bのローカルにはない——。本番にも忘れずに追加しなければならないが、手順書が存在しない——。

このような「環境ごとのDBスキーマ差異」が実務では頻繁に事故の原因になります。

マイグレーションはDBスキーマの変更をコードで記録することで、誰でも同じ順序で同じスキーマを再現できる仕組みです。

マイグレーションの実装（Phinx）


<?php
use Phinx\Migration\AbstractMigration;
class CreatePostsTable extends AbstractMigration {
    public function change(): void {
        $table = $this->table('posts');
        $table->addColumn('title', 'string', ['limit' => 255])
              ->addColumn('body', 'text')
              ->addColumn('user_id', 'integer')
              ->addTimestamps()
              ->create();
    }
}

手動変更 vs マイグレーション

観点 手動でALTER TABLE マイグレーション管理
変更の再現性 手順書頼み、漏れが出る コードで記録、誰でも再現
チーム開発 誰かが変更を見逃す migrate 一発で追従
ロールバック 手動で戻す必要あり rollback コマンドで戻せる
CI/CD 自動化できない パイプラインに組み込める

チェックポイント: Laravelでは php artisan make:migration でマイグレーションファイルを生成し、php artisan migrate で実行します。

Laravelでのマイグレーション


<?php
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration {
    public function up(): void {
        Schema::create('posts', function (Blueprint $table) {
            $table->id();
            $table->string('title');
            $table->text('body');
            $table->foreignId('user_id')->constrained();
            $table->timestamps();
        });
    }

    public function down(): void {
        Schema::dropIfExists('posts');
    }
};

チェックポイント: down() メソッドには必ず逆操作（テーブル削除やカラム削除）を書きましょう。rollback が使えることで本番適用のリスクが下がります。

まとめ & 次のステップ

  • マイグレーションはDBスキーマの変更をコードで管理し、環境差異を防ぐ
  • up() で変更を適用、down() でロールバックできる設計にする
  • CI/CDパイプラインに組み込むことで、デプロイと同時に安全にスキーマ変更できる

次回はクエリビルダの作り方を学びます。SQLを直書きせず、安全にクエリを組み立てる仕組みを自分で実装します。

Related Articles