GitHub Secrets × Neon で「ブランチごと専用DB」をサクッと用意するメモ

「GitHub の Secrets / Variables と Neon をどうつなぐと便利か

---

やりたいこと

• デフォルトの開発用データベースをみんなで共有すると、テストデータがぶつかる。
• 手作業で「テスト用DB」を作るのも管理がしんどい。

そこで、

GitHub のブランチや Pull Request ごとに、Neon 上に専用のDBブランチを自動で作る

というしくみを GitHub Actions で用意します。

鍵となるのが、GitHub の Secrets と Variables です。

---

まずはおさらい：Secrets と Variables の使い分け

GitHub の設定画面の「Settings → Secrets and variables → Actions」に、次の2つがあります。

• Secret
  パスワードやトークンなど、人に見せたくない値をしまっておく場所です。ログにもそのまま出ません。

• Variable（変数）
  プロジェクトIDやフラグなど、機密情報ではない設定値を入れておく場所です。

ワークフローの中では、こんなふうに使います。

# Secret の参照
api_key: ${{ secrets.NEON_API_KEY }}

# Variable の参照
project_id: ${{ vars.NEON_PROJECT_ID }}

Neon との連携では、ざっくり次のように役割を分けるとわかりやすいです。

• Secret: Neon の API キーや接続文字列
• Variable: Neon の Project ID やブランチ名のテンプレートなど

---

Neon と GitHub をつなぐ一番カンタンな方法

Neon には公式の GitHub 連携 が用意されています。これを使うと設定がかなり楽になります。

流れはだいたい次のとおりです。

1. Neon 側でプロジェクトを作る。

2. Neon のコンソールから GitHub 連携を開き、対象のリポジトリと接続する。

3. 接続が終わると、GitHub リポジトリ側に自動で次が追加される。

   • Secret: NEON_API_KEY
   • Variable: NEON_PROJECT_ID

これで、GitHub Actions から Neon API を呼ぶ準備が整います。

もし公式連携を使わない場合は、次のように手動で設定してもかまいません。

1. Neon のダッシュボードで API キーを発行する → GitHub の Secret NEON_API_KEY に保存する。
2. Neon の Project ID を確認する → GitHub の Variable NEON_PROJECT_ID に保存する。

---

サンプル：PR ごとに Neon ブランチを自動作成する

ここからが本題です。Neon の GitHub Action を使うと、Pull Request が作られたタイミングで Neon 上にブランチ（＝専用DB）を作れます。

たとえば、次のようなワークフローです。

name: DB preview (Neon)

on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  db-preview:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Create Neon branch for this PR
        id: neon-branch
        uses: neondatabase/create-branch-action@v6
        with:
          project_id: ${{ vars.NEON_PROJECT_ID }}
          branch_name: pr-${{ github.event.number }}
          api_key: ${{ secrets.NEON_API_KEY }}

      - name: Run DB migrations
        env:
          DATABASE_URL: ${{ steps.neon-branch.outputs.db_url }}
        run: |
          ./gradlew flywayMigrate

ポイントは3つだけです。

1. project_id に GitHub Variable の NEON_PROJECT_ID を渡す。
2. api_key に GitHub Secret の NEON_API_KEY を渡す。
3. Action が出力する db_url を、そのまま DATABASE_URL としてマイグレーションやテストに使う。

これで、PR ごとに きれいな専用DB が自動で立ち上がります。テストが終わったらブランチを削除するワークフローを足せば、環境の掃除も自動化できます。

---

ローカル開発と組み合わせる小ネタ

GitHub Actions だけでなく、ローカル開発でも同じ考え方で設定をまとめると楽です。

• .env や application-local.yml などに、DATABASE_URL だけを書く。
• CI（GitHub Actions）では、Neon のブランチURLを DATABASE_URL に上書きして使う。

「アプリは常に DATABASE_URL だけを見る」ようにしておくと、

• ローカルでは手動で指定したDBに接続
• CIでは PR ごとの Neon ブランチに接続

という切り替えが、設定ファイルの変更なしでできるようになります。

---

まとめ

• GitHub の Secrets には「鍵やパスワード」をしまう。
• GitHub の Variables には「プロジェクトIDやフラグ」をしまう。
• Neon の GitHub 連携を使うと、NEON_API_KEY（Secret）と NEON_PROJECT_ID（Variable）が自動で設定される。
• neondatabase/create-branch-action を使えば、PR ごとに Neon ブランチを自動作成して、その URL をそのまま DATABASE_URL として流用できる。

この組み合わせを覚えておくと、

「ブランチを切ったらDBも勝手に生えて、テストが終わったら勝手に消える」

という、気楽な開発フローが作れます。まずは小さな検証用リポジトリで試してみると、動きがつかみやすいと思います。