Declarative Automation Bundles×GitHubActionsで実践するDatabricks開発

GenAI 時代の Databricks 開発 Declarative Automation Bundles × GitHub Actions で実践する Databricks 開発 はじめてのCI/CD体験 Microsoft Data Analytics Day (Online) 勉強会 2026.10.29 (Thu.) 石川 貴啓

A G END A 本日の流れ P AR T 1 P AR T 2 P AR T 3 P AR T 4 Declarative Automation Bundles とは コードベース開発の利点 ブランチ戦略と CI/CD 安全に CI/CD を 実践するために リソースをコードにして束ねる Git と生成AI を活用できる feature/* → main → prod と GitHub Actions ブランチ保護ルール / 承認ゲート / 環境分離 / シークレット管理 アジェンダ Declarative Automation Bundles × GitHub Actions 3

Declarative Automation Bundles とは PART 1 PART 1 Databricks のリソース情報をコードにして、プログラムと一緒に束ねる仕組み。 Declarative Automation Bundles × GitHub Actions 5

PART 1 B U ND L ES B A S I CS Declarative Automation Bundles とは？ コードとして記述した Databricks のリソース情報と、関連するプログラムを、 ひとつのプロジェクトとして束ねる仕組み 旧称：Databricks Asset Bundles（DABs） ／ 中心となる設定ファイルは databricks.yml 実行するプログラム Databricks リソース 環境ごとの設定（targets） • Notebook • ジョブ・パイプライン • dev / prod などのデプロイ先 • Python / SQL • コンピュート • 環境で変わるパラメーター • カタログ Declarative（宣言的）とは？ 「画面でこう操作する」という手順ではなく、「こういう ジョブ が存在してほしい」というあるべき状態を書くこと。 PART 1 / Bundles とは Declarative Automation Bundles × GitHub Actions 6

PART 1 B U ND L ES B A S I CS Bundle のプロジェクト構成例 databricks.yml Bundle 全体の設定。名前・読み込むリソース・targets（環境）を定義 resources/**/*.yml ジョブ や パイプライン などのリソース定義 src/ Job が実行する Notebook・Python などのプログラム リソース情報とプログラムが、ひとつのフォルダにまとまる PART 1 / Bundles とは Declarative Automation Bundles × GitHub Actions 7

PART 1 B U ND L ES B A S I CS 実物で見る Bundles例：リソースを YAML で表現する(1) 1 2 3 4 bundle: プロジェクト（Bundle）の名前 include: databricks.ymlの一部として扱う構成ファイル variables: 変数定義 targets: dev / stg / prod などの環境ごとの設定 手順ではなく「あるべき状態」を宣言 PART 1 / Bundles とは Declarative Automation Bundles × GitHub Actions 8

PART 1 B U ND L ES B A S I CS 実物で見る Bundles例：リソースを YAML で表現する(2) 1 2 3 4 resources: ジョブやパイプライン等のリソース設定 jobs: ジョブの設定 task: ジョブのタスクに関する設定 base_parameters: タスクのノートブックに外から渡すパラメータ 手順ではなく「あるべき状態」を宣言 PART 1 / Bundles とは Declarative Automation Bundles × GitHub Actions 9

コードベース開発の利点 PART 2 PART 2 リソースがコードになったから、Git と生成AI を活用できる。 Declarative Automation Bundles × GitHub Actions 10

PART 2 C O D E - B A S E D D E V E LO P ME N T コードになると開発ツールの恩恵を受けられる 利点① Git で変更を管理できる 差分・変更者・レビュー履歴を残せる Bundles リソース情報とプログラムが コード（テキスト）になる 利点② 生成AI の支援を受けやすい 作成・修正・説明・レビューを依頼できる Bundles に Git や生成AI の機能があるのではなく、「コードになったから」使えるようになる PART 2 / コードベース開発の利点 Declarative Automation Bundles × GitHub Actions 11

PART 2 C O D E - B A S E D D E V E LO P ME N T 利点① Git で変更を管理・レビューできる 何を変えたか 変更前後の差分を行単位で確認できる 誰が・いつ変えたか コミット履歴として追跡できる レビューしてから取り込む Pull Request で確認・コメントできる 以前の状態に戻れる 過去の定義を参照・復元できる PART 2 / コードベース開発の利点 Declarative Automation Bundles × GitHub Actions 12

PART 2 C O D E - B A S E D D E V E LO P ME N T 利点② 生成AI のアシストを受けやすい SCREENSHOT ④ こんな依頼ができる 作成 「このノートブックを実行するジョブ定義を追加して」 修正 「dev と prod でテーブル名を次のように修正して。 …」 説明 「この YAML が何を定義しているかコメントを書いて」 レビュー 「本番に影響する変更がないか確認して」 ただし、AI の出力がそのまま正しいとは限らない → 変更を確認してから届ける仕組みが必要 PART 2 / コードベース開発の利点 Declarative Automation Bundles × GitHub Actions 13

ブランチ戦略と CI/CD PART 3 PART 3 コードの変更を、段階的に・自動で・安全に本番へ届ける。 Declarative Automation Bundles × GitHub Actions 14

PART 3 B R A N C H S TR A TE G Y 構成例 ブランチと Databricks ワークスペースの対応 GitHub リポジトリ databricks.yml 4 CI 合格後に PR 3 push をトリガーに CI 実行 （validate / test） prod 承認済みの変更 本番に入っている状態 1 main の最新を 個人フォルダへ pull PR 承認・マージで CD 個人フォルダ PR 承認・マージで CD 5 GitHub Actions (CDワークフロー)が 7 GitHub Actions (CDワークフロー)が bundle deploy -t stg bundle deploy -t prod $ git checkout main $ git pull origin main 開発用 Databricks ワークスペース （feature/** と main で共用） フォルダ .github/workflows/ main feature/** を切って commit & push $ git checkout -b feature/xxx $ git add . $ git commit -m "..." $ git push -u origin feature/xxx src/ 6 prod へ PR feature/** 2 resources/ 本番用 Databricks ワークスペース フォルダ 共有フォルダ フォルダ 共有フォルダ /Workspace/Users/<自分>/<bundle名> /Workspace/Shared/<bundle名> /Workspace/Shared/<bundle名> 編集：ソース・YAML をここで編集 デプロイ：開発者本人（自分の変更だけ試す） 編集：しない（デプロイ結果の置き場） デプロイ：SP（dev 用）が承認済み変更を反映 編集：しない（デプロイ結果の置き場） デプロイ：SP（prod 用）が本番へ反映 リソース ジョブ・パイプライン 名前に [dev <自分>] が付いた自分専用リソース 確認：UI で動かして結果を確認 リソース ジョブ・パイプライン 統合版（stg）のリソース 確認：UI で統合後の動作を確認 リソース ジョブ・パイプライン 本番運用のリソース 確認：UI で実行状況・失敗を監視 ブランチ＝変更の段階、targets＝デプロイ先。ファイルはフォルダで編集し、デプロイで作られたリソース（ジョブ・パイプライン）は UI で確かめる ※ ブランチ名・target 名・フォルダ配置はサンプル。チームの人数や環境の数に合わせて調整してください PART 3 / ブランチ戦略と CI/CD Declarative Automation Bundles × GitHub Actions 16

PART 3 CI / CD W IT H GI T HU B A CT ION S ブランチごとに、GitHub Actions が動く きっかけ 種別 GitHub Actions / GitHub で行うこと 反映先 feature/* への push CI bundle validate ／ 単体テスト ／ Lint なし（検証のみ） feature/* → main の PR レビュー CI 合格を条件に、差分をレビュー・承認 なし（承認待ち） main へのマージ CD bundle validate → bundle deploy -t dev 検証環境 main → prod の PR レビュー CI 再実行 ＋ リリース差分のレビュー・承認 なし（承認待ち） prod へのマージ CD bundle deploy -t prod 本番環境 CI：変更を取り込んでよいか確認する CD：確認済みの変更を環境へ届ける ※ どのブランチで何を動かすかは、.github/workflows/<workflow_name>.yml に定義する PART 3 / ブランチ戦略と CI/CD Declarative Automation Bundles × GitHub Actions 17

PART 3 CI / CD W IT H GI T HU B A CT ION S GitHub Actions のワークフロー定義例 1 2 3 4 .github/workflows/<workflow_name>.yml ワークフローと呼ばれるCI/CDパイプライン定義ファイル on: branches: どのブランチへの push・PR で動くか bundle validate Bundle の構成・設定を検証 bundle deploy -t 指定した target（環境）へ反映 validate ≠ テスト validate は Bundle 設定の検証。Python 等の処理の 正しさは、単体テストを別ステップで実行して確認する PART 3 / ブランチ戦略と CI/CD Declarative Automation Bundles × GitHub Actions 18

PART 3 CI / CD W IT H GI T HU B A CT ION S GitHub Actions の実行結果を確認する SCREENSHOT ⑥ SCREENSHOT ⑦ CI の結果：取り込んでよいか CD の結果：どこへ・何が反映されたか 失敗した場合は、ここでどのステップで止まったかを確認できる PART 3 / ブランチ戦略と CI/CD Declarative Automation Bundles × GitHub Actions 19

PART 3 CI / CD W IT H GI T HU B A CT ION S YAML で定義した Job が Databricks に現れる YAML で定義 PART 1 で見た Job 定義 ▼ GitHub Actions で deploy PR 承認・マージ後、ブランチに応じた target へ ▼ Databricks に反映 Jobs 画面で確認 PART 3 / ブランチ戦略と CI/CD Declarative Automation Bundles × GitHub Actions 20

安全に CI/CD を実践するために PART 4 PART 4 自動化は便利。だからこそ、最初に2つのガードレールを GitHub で設定する。 Declarative Automation Bundles × GitHub Actions 21

PART 4 G UAR D RAIL S まず押さえたい 2 つのガードレール 1 ブランチルール 2 環境分離 main / prod に入る変更を絞る どこへ・誰の権限でデプロイするかを絞る ・ force push・削除等の禁止事項を設定 ・ stg / prod を Environment で分ける ・ 承認ゲート：PR の承認を必須に ・ Variables・Secrets を環境ごとに管理 GitHub：Rulesets GitHub：Environments PART 4 / 安全に CI/CD を実践するために Declarative Automation Bundles × GitHub Actions 22

PART 4 G UAR D RAIL 1 / 2 ガードレール① ブランチルールで入口を守る SCREENSHOT ⑨ ルールセットを定義する リポジトリのSettings → Rules → Rulesets から作成 対象ブランチを指定する Target branches で main / prod を指定 バイパスリストは最小限に 登録した人・アプリはルールを素通りできる 守らせるルールを選ぶ PR 必須・CI 必須など。承認ゲートの例は次頁 どのブランチで・誰に・何を守らせるかを決める PART 4 / 安全に CI/CD を実践するために Declarative Automation Bundles × GitHub Actions 23

PART 4 G UAR D RAIL 1 / 2 ガードレール① 承認ゲート、禁止事項を設定する PR を必須にする main / prod への直接 push を禁止 承認ゲート：承認数 1 以上 Required approvals で承認までマージ不可 force push を禁止する Block force pushes で履歴の書き換えを防ぐ 1人開発でも承認は見直しの場 マージ前に差分とデプロイ先を確認 うかつな変更の反映をチームの運用ルールとして ケアする PART 4 / 安全に CI/CD を実践するために Declarative Automation Bundles × GitHub Actions 24

PART 4 G UAR D RAIL 2 / 2 ガードレール② 環境を分離する stg / prod を Environment で分ける ワークフローの job に environment: <環境名>を指定 デプロイできるブランチを限定 prod 環境は prod ブランチからのみ実行可 Variables・Secrets は環境ごとに prod 用の値は prod 環境の job だけが参照 権限は最小限に stg 用・prod 用でサービスプリンシパルを分ける feature/** から本番に届く道を、設定で塞ぐ PART 4 / 安全に CI/CD を実践するために Declarative Automation Bundles × GitHub Actions 25

PART 4 G UAR D RAIL 2 / 2 ガードレール② Variables と Secrets を使う NG：コードに直接書く DATABRICKS_CLIENT_SECRET: xxxxxxxx Git の履歴に残り、閲覧できる人に漏れる OK：Variables / Secrets で参照 ${{ secrets.DATABRICKS_CLIENT_SECRET }} 秘密でない値は variables、秘密は secrets。ログ上もマスク さらに一歩：長期トークンをなくす サービスプリンシパル＋OIDC 連携で、保存する秘密情報自体を 減らす 秘密情報を適切に運用する PART 4 / 安全に CI/CD を実践するために Declarative Automation Bundles × GitHub Actions 26

まとめ PART 1 Bundles は、コードにしたリソース情報とプログラムを束ねる仕組み PART 2 コードになるから、Git で変更を管理でき、生成AI のアシストも受けやすい PART 3 push で CI、PR 承認⇒マージで CD。 feature/* → main → prod と段階的に届ける PART 4 ブランチ保護ルール・承認ゲート・環境分離・認証情報の管理で安全に運用する はじめの一歩：まずは Job を1つ Bundle にして、feature/* への push で validate を動かすところから Thank you / Q&A まとめ Declarative Automation Bundles × GitHub Actions 27

参考 APPENDIX APPENDIX 生成AI に指示するときに使えるリンク集 Declarative Automation Bundles × GitHub Actions 28

APPENDIX 1 / 4

D AT AB RIC KS B UND L E S

Declarative Automation Bundles の定義
項目

AI に伝えるとよいキーワード（プロパティ名など）

参考ドキュメント

Bundle の構成（databricks.yml）

バンドルの構成

bundle / include / targets /
workspace / run_as / sync

https://learn.microsoft.com/ja-jp/azure/databricks/devtools/bundles/settings

構成リファレンス（全キー）
https://learn.microsoft.com/ja-jp/azure/databricks/devtools/bundles/reference

各リソースの定義

resources.jobs / resources.pipelines
tasks / job_clusters / schedule

変数の宣言と参照

variables: / ${var.<name>}
${bundle.target} / ${workspace.host}

Bundle のリソース（種類別のキーと例）
https://learn.microsoft.com/ja-jp/azure/databricks/devtools/bundles/resources

置換と変数
https://learn.microsoft.com/ja-jp/azure/databricks/devtools/bundles/variables

コンテキスト（vars / secrets）

GitHub Actions からの値 ${{ vars.X }} / ${{ secrets.X }}
BUNDLE_VAR_<name> / --var
の受け渡し

https://docs.github.com/ja/actions/reference/workflows-andactions/contexts

Bundle 変数への値の設定方法
https://learn.microsoft.com/ja-jp/azure/databricks/devtools/bundles/variables

bundle コマンド

APPENDIX / 参考リンク集

databricks bundle validate / deploy
-t <target> / bundle schema

bundle コマンド グループ
https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/cli/bundlecommands

Declarative Automation Bundles ×
GitHub Actions

29

• https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/bundles/settings
• https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/bundles/reference
• https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/bundles/resources
• https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/bundles/variables
• https://docs.github.com/ja/actions/reference/workflows-and-actions/contexts
• https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/cli/bundle-commands

APPENDIX 2 / 4 GI T HU B AC T IONS GitHub 側の設定 項目 AI に伝えるとよいキーワード（プロパティ名など） 参考ドキュメント ルールセットについて ブランチ保護ルール Rulesets / Require a pull request Require status checks / Block force pushes https://docs.github.com/ja/repositories/configuring-branches-and-mergesin-your-repository/managing-rulesets/about-rulesets 保護されたブランチについて https://docs.github.com/ja/repositories/configuring-branches-and-mergesin-your-repository/managing-protected-branches/about-protected-branches ブランチ戦略 push: branches: [feature/**] pull_request: branches: [main, prod] GitHub Actions のシーク レット Repository secrets / Environment secrets ${{ secrets.NAME }} GitHub フロー（ブランチ運用の基本） https://docs.github.com/ja/get-started/using-github/github-flow GitHub Actions でのシークレットの使用 https://docs.github.com/ja/actions/how-tos/write-workflows/choose-whatworkflows-do/use-secrets デプロイ環境の管理 承認ゲート environment: prod / Required reviewers Prevent self-review / Deployment branches https://docs.github.com/ja/actions/how-tos/deploy/configure-and-managedeployments/manage-environments デプロイと環境（保護ルールの一覧） https://docs.github.com/ja/actions/reference/workflows-andactions/deployments-and-environments APPENDIX / 参考リンク集 Declarative Automation Bundles × GitHub Actions 30

• https://docs.github.com/ja/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets
• https://docs.github.com/ja/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
• https://docs.github.com/ja/get-started/using-github/github-flow
• https://docs.github.com/ja/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets
• https://docs.github.com/ja/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments
• https://docs.github.com/ja/actions/reference/workflows-and-actions/deployments-and-environments

APPENDIX 3 / 4 CO N N EC TI O N & T O O L S Databricks と GitHub Actions の接続設定・その他 項目 サービスプリンシパルの構成 AI に伝えるとよいキーワード（プロパティ名など） service principal / application ID ワークスペースへの割り当て / 権限 参考ドキュメント サービスプリンシパルの管理 https://learn.microsoft.com/ja-jp/azure/databricks/admin/usersgroups/manage-service-principals GitHub Actions のワークロード ID フェデレーション フェデレーション設定（OIDC DATABRICKS_AUTH_TYPE: github-oidc permissions: id-token: write / subject ） https://learn.microsoft.com/ja-jp/azure/databricks/devtools/auth/provider-github フェデレーション ポリシーの構成 https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/auth/oauthfederation-policy Databricks 公式 Action databricks/setup-cli DATABRICKS_HOST / DATABRICKS_CLIENT_ID GitHub Actions（Databricks 公式の例） https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/ci-cd/github Databricks IDE 拡張機能 ワークスペースと VS Code の接続 APPENDIX / 参考リンク集 Databricks extension for VS Code Bundle explorer / Databricks Connect https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/vscode-ext/ 拡張機能のインストール https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/vscodeext/install Declarative Automation Bundles × GitHub Actions 31

• https://learn.microsoft.com/ja-jp/azure/databricks/admin/users-groups/manage-service-principals
• https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/auth/provider-github
• https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/auth/oauth-federation-policy
• https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/ci-cd/github
• https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/vscode-ext/
• https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/vscode-ext/install

APPENDIX 4 / 4 PROM PT T IP S 生成AI への指示例：プロパティを添えて頼む あいまいな頼み方 「本番だけ毎朝動く Job を作って」 ・存在しないキーを作られる可能性がある ・Productionモードの環境すべてを本番と認識される可能性がある。 ・dev にもスケジュールが入ったりしやすい プロパティとドキュメントを添えた頼み方 resources/daily_sales.job.yml に Job を追加して。 ・resources.jobs に daily_sales_job を定義 ・notebook_task で ../src /aggregate_sales.py を実行 ・schedule.quartz_cron_expression で毎朝 6 時（Asia/Tokyo） ・targets.dev では schedule.pause_status を PAUSED に 頼み方のコツ • ファイルの場所とプロパティ名を指定する • 環境（targets）ごとの違いを明示する • 公式ドキュメントの URL を添える ・キーは次のドキュメントにあるものだけ使って： - .../dev-tools/bundles /resources プロパティ名・環境ごとの違い・公式ドキュメントを添えて頼むことでハルシネーションをケアする APPENDIX / 参考リンク集 Declarative Automation Bundles × GitHub Actions 32