目次 › 第5章 › 5-2

第5章 CI/CDの実装 / 想定学習時間:30〜40分 / 最終確認:2026年8月

5-2. Declarative Automation Bundles(旧 Databricks Asset Bundles)と環境別デプロイ

1. Automation Bundle とは:資産をコードとして定義する

Declarative Automation Bundles(旧 Databricks Asset Bundles)は、ジョブやパイプラインといったワークスペース資産を YAML ファイル(databricks.yml)でコードとして宣言的に定義し、ソースコードと一緒にパッケージ化・構成・昇格(dev → test → prod)するための仕組みです。かつては「Databricks Asset Bundles(略称 DABs)」という名称で、現在は「Declarative Automation Bundles」(個々のバンドルは「Automation Bundle」)に改名されていますが、仕組みはそのまま引き継がれています(本書では以降「Automation Bundle」または単に「Bundle」と表記します)。

Bundle が解決するのは「UI で手作業で作ったジョブは、別の環境に正確に再現できない」という問題です。ジョブの定義・パイプラインの設定・ソースコードを1つのプロジェクトとしてまとめ、同じ定義ファイルからどの環境にも同じものをデプロイできるようにします。これは一般に IaC(Infrastructure as Code)と呼ばれる考え方の Databricks 版です。

2. Bundle に含められる資産

1つの Bundle には、プロジェクトを構成する複数の資産をまとめて定義できます。

つまり「パイプライン本体+それを動かすジョブ+ソースコード」という一連のまとまりを、1つのバージョン管理されたプロジェクトとして扱えます。Bundle のプロジェクトは 5-1 で学んだ Git リポジトリに置き、Git Folders・PR・CI/CD と組み合わせて運用します。

3. databricks.yml の基本構造

Bundle の中心となるのが、プロジェクトのルートに置く databricks.yml です。最低限の構造は次の3ブロックです。

• bundle — Bundle の名前などプロジェクト全体の情報
• resources — デプロイする資産(ジョブ、パイプライン等)の定義
• targets — デプロイ先の環境(dev / test / prod)ごとの設定

# databricks.yml — Bundle 定義の最小例
bundle:
  name: sales_etl            # Bundle(プロジェクト)の名前

variables:
  catalog:                   # 環境ごとに差し替える変数
    default: dev_catalog

resources:
  jobs:
    daily_sales_job:         # ジョブをコードとして定義
      name: daily-sales-etl
      tasks:
        - task_key: run_etl
          notebook_task:
            notebook_path: ./src/etl_notebook.py
            base_parameters:
              catalog: ${var.catalog}   # 変数を参照

targets:
  dev:
    default: true            # 省略時のデプロイ先
    workspace:
      host: https://dev-workspace.example.databricks.net
  test:
    workspace:
      host: https://test-workspace.example.databricks.net
    variables:
      catalog: test_catalog  # test では変数をオーバーライド
  prod:
    workspace:
      host: https://prod-workspace.example.databricks.net
    variables:
      catalog: prod_catalog  # prod 用の値に差し替え

4. targets と variables:同一コードベースを環境ごとに差し替える

環境別デプロイの中核となる考え方は「コードは1つ、設定は環境ごと」です。

これにより、dev で動作確認したものとまったく同じ定義が test・prod へ昇格していきます。「prod だけ手作業で設定したので dev と挙動が違う」という事故を仕組みで防げるのが Bundle の価値です。

この昇格を CI/CD パイプラインから自動実行する方法(CLI コマンド、認証、GitHub Actions への組み込み)は次の 5-3 で扱います。

5. Bundle が正解になる典型パターン

試験では「どの仕組みを使うべきか」を選ばせる形式で Bundle が問われます。次のキーワードが要件に含まれていたら、Automation Bundle(旧 Asset Bundles)が正解の候補です。

• モジュール化されたデプロイ — ジョブ・パイプライン・コードを1つの単位としてまとめて展開したい
• バージョン管理 — 資産の定義を Git で管理し、変更履歴を追跡・ロールバックしたい
• CI/CD の再現性 — どの環境にも同じ手順・同じ定義でデプロイし、環境差分を設定だけに閉じ込めたい
• 環境ごとの構成差し替え — dev/test/prod でカタログ名やスケジュールだけを変えたい

練習問題