CI/CDでデータベースマイグレーションをどのように扱いますか？

Question

Accepted Answer

**データベースマイグレーション**（スキーマ変更）は、CI/CDの中で最も扱いの難しい部分の一つです——ステートレスなアプリケーションコードとは異なり、データベースは単純に置き換えたりロールバックしたりできない **状態（state）** を保持します。マイグレーションを慎重に扱うこと（自動化、後方互換性、安全なパターン）が、信頼性の高いデプロイには不可欠です。

## なぜデータベースマイグレーションは難しいのか

```text
App code is stateless (replace it, roll back freely). DATABASES hold STATE:
  → can't just "roll back" a migration that dropped a column or transformed data
    (the data may be gone) → rollbacks are risky/impossible for destructive changes
  → during deployment, OLD and NEW app code may run SIMULTANEOUSLY (rolling deploy) —
    both must work with the database schema at that moment
→ Schema changes need careful coordination with code deployment.
```

## パイプラインでのマイグレーションの自動化

```text
→ Migrations defined as CODE (versioned migration files; Flyway, Liquibase, ORM tools)
→ Run migrations as a pipeline STEP (apply pending migrations on deploy)
→ Migrations are versioned and applied in order, idempotently
→ Test migrations in staging before production
```

## 安全なマイグレーションパターン（後方互換性）

```text
KEY PRINCIPLE: make migrations BACKWARD-COMPATIBLE so old AND new code both work during
the transition. Use the EXPAND-CONTRACT (parallel change) pattern:
  1. EXPAND → add the new schema (e.g. add a new column) — old code still works
  2. MIGRATE → deploy code that writes to both / reads new; backfill data
  3. CONTRACT → once all code uses the new schema, remove the old (in a LATER deploy)
→ NEVER drop/rename in the same deploy that needs it gone — split across deploys.
→ This enables zero-downtime deploys and safe rollbacks.
```

## なぜ重要なのか

CI/CDでデータベースマイグレーションをどう扱うかを理解することは重要です。なぜなら、**マイグレーションは自動化されたデプロイの中で最も難しくリスクの高い部分の一つ** であり、信頼性の高いデリバリーにとって価値ある実践的な知識だからです。

中核となる課題は、ステートレスなアプリケーションコード（自由に置き換えロールバックできる）とは異なり、**データベースは状態を保持する** ことです——そのため、カラムを削除したりデータを変換したりするマイグレーションは **単純にロールバックできず**（データが失われている可能性がある）、破壊的な変更をリスキーまたは不可逆なものにし、ローリングデプロイ中には **古いコードと新しいコードが同時に動作** し、両方がその時点のスキーマで動作する必要があります。

これにより、スキーマ変更はCI/CDの他の部分とは異なり、慎重な調整を必要とします。

**マイグレーションを自動化する** 方法（Flyway、Liquibase、ORMマイグレーションのようなツールでバージョン管理されたコードとして定義し、順序通り冪等に適用するパイプラインステップとして実行し、まずステージングでテストする）を理解することで、マイグレーションを安全に自動パイプラインに取り込めます。

最も重要なのは、**安全なマイグレーションパターン** を理解することです——移行中に古いコードと新しいコードの両方が動作するようマイグレーションを **後方互換性のある** ものにすること、**expand-contract（並行変更）パターン** を使うこと（expand：古いコードを壊さずに新しいスキーマを追加する、migrate：コードを移行しデータをバックフィルする、contract：後のデプロイで古いスキーマを削除する）、そして **削除が必要なものを同じデプロイで削除・リネームしない** こと——これこそが、データベースのステートフルな性質にもかかわらず **ゼロダウンタイムのデプロイと安全なロールバック** を可能にする鍵となるスキルです。

これは真に扱いが難しく重要な実世界の知識であり、データベース変更を安全にデプロイできる人と、障害やデータ損失を引き起こす人を分けるものです。

データベースマイグレーションはデータベースを持つアプリケーションをデプロイする上で難しく、リスクが高く、避けられない部分であり、それらを慎重に扱うこと（自動化に加えて後方互換性のあるexpand-contractパターン）が信頼性の高いゼロダウンタイムのデプロイに不可欠であることから、CI/CDにおけるデータベースマイグレーションを理解することは価値があり実践的に重要な知識であり、継続的デリバリーの中で最も扱いの難しい側面の一つに対処し、ステートフルなアプリケーションを安全にデプロイするために必要な成熟度を反映します。