GitHub Actions による Databricks Apps の CI/CD

このページでは、GitHub Actionsと Declarative Automation Bundles を使用して、GitHubから Databricks アプリのデプロイを自動化する方法について説明します。ワークロード ID フェデレーション、ワークフロー YAML、および各デプロイ後にアプリが最新のコードを提供していることを確認する正常性チェックについて説明します。

Azure Databricksジョブとパイプラインの一般的なGitHub Actionsガイダンスについては、GitHub Actionsを参照してください。ワークロード ID フェデレーションのセットアップについては、GitHub Actions のワークロード ID フェデレーションを有効にするを参照してください。

Note

ブランチへのプッシュごとにアプリを自動的に再デプロイするには、自動 Git デプロイ (ベータ) を使用します。 Git の自動デプロイを有効にするを参照してください。

Requirements

デプロイされたアプリを所有するAzure Databricks アカウント内のサービスプリンシパル。「アカウントにサービスプリンシパルを追加する」を参照してください。
アプリをリソースとして宣言するGitHub リポジトリのルートにある databricks.yml バンドル構成。アプリを参照してください。
1 回限りのセットアップタスク用にローカルにインストールされた Databricks CLI。「Databricks CLI のインストールまたは更新」を参照してください。

手順 1、ワークロード ID フェデレーションの構成

ワークロード ID フェデレーションを使用すると、GitHub Actions ランナーは、リポジトリに資格情報を格納するのではなく、有効期間の短い OIDC トークンを使用してAzure Databricksで認証できます。

GitHub Actions のワークロード ID フェデレーションを有効にするの手順に従って、サービスプリンシパルに GitHub Actions フェデレーションポリシーを作成します。サービスプリンシパルアプリケーション ID (UUID) とワークスペースの URL を記録します。ワークフロー内の変数として両方が必要です。
アプリに対するアクセス許可 CAN MANAGE サービスプリンシパルに付与するか、アプリがまだ存在しない場合はワークスペースにアプリを作成するアクセス許可を付与します。 Databricks アプリのアクセス許可の構成を参照してください。

手順 2、 GitHub リポジトリを構成する

GitHub リポジトリで、ワークスペース接続変数を格納するデプロイ環境を作成します。環境を使用すると、デプロイを実行する前に手動承認を必要とすることもできます。

[設定]>Environments で、prod (またはワークフロー参照の任意の名前) という名前の環境を作成します。
環境変数の場合は、次を追加します。

Variable	Value
`DATABRICKS_HOST`	ワークスペースの URL (例: `https://my-workspace.cloud.databricks.com`
`DATABRICKS_CLIENT_ID`	手順 1 のサービスプリンシパルアプリケーション ID

どちらの値も資格情報ではありません。サービスプリンシパルのフェデレーションポリシーは、認証できるユーザーを制御するため、クライアント ID だけではアクセス権は付与されません。クライアントシークレットは必要ありません。

ステップ 3。運用環境のデプロイ用にバンドルを構成する

databricks.ymlで、host ターゲットで明示的なワークスペースのroot_pathとprodを宣言します。これにより、すべての実行でバンドルが同じ場所に確実にデプロイされます。運用モードの検証では、 run_as がサービスプリンシパルに設定されていない限り、両方のフィールドが必要です。宣言型オートメーションバンドルのデプロイモードを参照してください。

Git ソース

git_sourceを使用して、ファイルをワークスペースにアップロードするのではなく、Git リポジトリから直接コードをプルします。これにより、追加の sync 手順が回避され、デプロイされたコードがリポジトリと同期されます。

targets:
  prod:
    mode: production
    workspace:
      host: https://my-workspace.cloud.databricks.com
      root_path: /Workspace/Users/<service-principal-or-owner>/.bundle/${bundle.name}/${bundle.target}
    resources:
      apps:
        my_app:
          name: my-app
          git_repository:
            url: https://github.com/org/repo
          git_source:
            branch: main
            source_code_path: apps/my-app

<service-principal-or-owner>を、バンドル成果物 (通常はサービスプリンシパルアプリケーション ID) を所有するワークスペースユーザーに置き換えます。 git_repository URL を、GitHub リポジトリの URL に置き換えます。アプリコードがリポジトリルートにある場合は、 source_code_pathを省略します。アプリを参照してください。

プライベートリポジトリの場合は、デプロイする前に、アプリのサービスプリンシパルで Git 資格情報を構成します。 Git リポジトリからのデプロイの CLI の手順を参照してください。

ワークスペースのソース元

source_code_pathを使用して、デプロイ時にローカルリポジトリからワークスペースにアプリファイルをアップロードします。

targets:
  prod:
    mode: production
    workspace:
      host: https://my-workspace.cloud.databricks.com
      root_path: /Workspace/Users/<service-principal-or-owner>/.bundle/${bundle.name}/${bundle.target}
    resources:
      apps:
        my_app:
          name: my-app
          source_code_path: ./app

<service-principal-or-owner>を、バンドル成果物 (通常はサービスプリンシパルアプリケーション ID) を所有するワークスペースユーザーに置き換えます。 ./appを、databricks.ymlを基準としたアプリのソースコードへのパスに置き換えます。アプリを参照してください。

手順 4、デプロイワークフローを追加する

リポジトリに .github/workflows/deploy.yml を追加します。

name: Deploy to Databricks Apps

on:
  workflow_dispatch:
  # Uncomment to deploy on every push to main once the workflow is validated.
  # push:
  #   branches: [main]

permissions:
  id-token: write # required for OIDC federation
  contents: read

jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    environment: prod
    env:
      DATABRICKS_AUTH_TYPE: github-oidc
      DATABRICKS_HOST: ${{ vars.DATABRICKS_HOST }}
      DATABRICKS_CLIENT_ID: ${{ vars.DATABRICKS_CLIENT_ID }}
    steps:
      - uses: actions/checkout@v4

      - name: Install Databricks CLI
        uses: databricks/setup-cli@main

      - name: Validate bundle
        run: databricks bundle validate --target prod

      - name: Deploy bundle
        run: databricks bundle deploy --target prod

      - name: Start or restart app
        run: databricks bundle run my_app --target prod

最後の手順のmy_appを、databricks.ymlの下でresources.appsが使用するリソースキーに置き換えます。

ランナーには、OIDC トークンを要求するための id-token: write アクセス許可が必要です。 databricks/setup-cliアクションは、DATABRICKS_AUTH_TYPE=github-oidcを読み取り、認証を自動的に処理します。

警告

databricks bundle deploy はソースコードをアップロードし、リソースを更新しますが、アプリプロセスは再起動されません。最後の databricks bundle run 手順をスキップすると、アプリが前のコードを引き続き提供している間、デプロイは CI で渡されます。デプロイ後は常にバンドルリソースを実行します。

手順 5、アプリが正常になるのを待つ

Databricks では、デプロイ後に状態ポーリング手順を追加することをお勧めします。 databricks bundle run は、アプリの起動を通知するとすぐに終了しますが、アプリがまだ実行されていない可能性があります。依存関係の不足、環境変数の不足、ポートの競合などの問題が原因で、起動中も失敗する可能性があります。ポーリングステップを追加すると、起動に失敗した場合にもワークフローが失敗するようになります。

- name: Wait for app to be running
  env:
    APP_NAME: my-app
  run: |
    for i in $(seq 1 20); do
      STATE=$(databricks apps get "$APP_NAME" --output json | jq -r '.app_status.state')
      echo "Attempt $i/20: state=$STATE"
      if [ "$STATE" = "RUNNING" ]; then
        exit 0
      fi
      sleep 15
    done
    echo "App did not reach RUNNING state within 5 minutes" >&2
    exit 1

APP_NAMEを、バンドルリソースキーではなく、databricks.ymlがresources.apps.<key>.nameで宣言する値に設定します。

既存のアプリの処理

アプリ名はワークスペース全体で一意です。別のバンドル (または手動で作成されたアプリ) がその名前のアプリを既に所有している場合、 bundle deploy ステップは An app with the same name already exists で失敗します。バンドルを再作成するのではなく、既存のアプリにバインドします。

これをローカルで 1 回実行して、バンドルを既存のアプリにアタッチします。

databricks bundle deployment bind my_app <existing-app-name> --target prod --auto-approve

次に、ワークフローを再実行します。後続のデプロイでは、バインディングが再利用されます。

既存のアプリに、budget_policy_idにないサーバー側の構成 (databricks.yml など) がある場合は、再デプロイする前にバンドルファイルにコピーします。不一致は、バンドルのデプロイ手順中に Terraform の "一貫性のない結果" エラーとして表示されます。

トリガーの選択

最初のデプロイが手動で行われるように、 workflow_dispatch から始めます。数回の実行が成功したら、すべてのマージにデプロイする push: branches: [main] を追加します。

追加の安全ゲートとして、prod環境は、Settings>Environments>prod>Deployment protection rules で必須のレビュアーを設定して構成します。ワークフローの各実行は、デプロイジョブが開始される前に承認者による承認を待機します。

その他のリソース

ワークロード ID フェデレーションを設定して、サービスプリンシパルにGitHub Actionsフェデレーションポリシーを構成します。
アプリをバンドルリソースとして宣言し、アプリを databricks.ymlに追加します。
アプリのアクセス許可を構成して、デプロイされたアプリを管理または使用できるユーザーを制御します。
バンドルのライフサイクルとデプロイモードの詳細については、宣言型オートメーションバンドルについて説明します。
アプリ以外のジョブとパイプラインに関するガイダンスについては>Azure Databricks

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-06-24

GitHub Actions による Databricks Apps の CI/CD

Requirements

手順 1、 ワークロード ID フェデレーションの構成

手順 2、 GitHub リポジトリを構成する

ステップ 3。 運用環境のデプロイ用にバンドルを構成する

Git ソース

ワークスペースのソース元

手順 4、 デプロイ ワークフローを追加する

手順 5、 アプリが正常になるのを待つ

既存のアプリの処理

トリガーの選択

その他のリソース

フィードバック

その他のリソース

手順 1、ワークロード ID フェデレーションの構成

ステップ 3。運用環境のデプロイ用にバンドルを構成する

手順 4、デプロイワークフローを追加する

手順 5、アプリが正常になるのを待つ