---
title: Declarative Automation Bundles×GitHubActionsで実践するDatabricks開発
tags: 
author: [takahiro_ishikawa](https://www.docswell.com/user/takahiro-dev)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/KJ4ZRGNM71.jpg?width=480
description: Declarative Automation Bundles×GitHubActionsで実践するDatabricks開発 by takahiro_ishikawa
published: October 30, 26
canonical: https://www.docswell.com/s/takahiro-dev/ZGNPQJ-2026-10-30-093322
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/KJ4ZRGNM71.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/LE1RQD5YEG.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/GEW1MY5172.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/47ZPQXNXE3.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/YJ6M648P7V.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/GJ5Z6Q9PE4.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/9E2RMP2ZJR.jpg)

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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/D7YDX5YN7M.jpg)

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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/VEN61NPVE8.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/Y79L5R3VJ3.jpg)

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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/G78XYWM4ED.jpg)

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


# Page. 12

![Page Image](https://bcdn.docswell.com/page/L7L84N3VJR.jpg)

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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/4EM6KXDN7W.jpg)

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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/PERPXN4479.jpg)

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


# Page. 15

![Page Image](https://bcdn.docswell.com/page/P7X36N2ZEX.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/37KY1NMVED.jpg)

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


# Page. 17

![Page Image](https://bcdn.docswell.com/page/LJ39QV2QJ5.jpg)

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


# Page. 18

![Page Image](https://bcdn.docswell.com/page/8JDG98ZWJG.jpg)

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


# Page. 19

![Page Image](https://bcdn.docswell.com/page/VEP3Z8DX78.jpg)

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


# Page. 20

![Page Image](https://bcdn.docswell.com/page/27V4WN13EQ.jpg)

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


# Page. 21

![Page Image](https://bcdn.docswell.com/page/5JG1DK2Y7L.jpg)

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


# Page. 22

![Page Image](https://bcdn.docswell.com/page/47QD1NP6EP.jpg)

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


# Page. 23

![Page Image](https://bcdn.docswell.com/page/KE4ZRGYMJ1.jpg)

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


# Page. 24

![Page Image](https://bcdn.docswell.com/page/L71RQD6Y7G.jpg)

まとめ
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


# Page. 25

![Page Image](https://bcdn.docswell.com/page/G7W1MYW1J2.jpg)

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


# Page. 26

![Page Image](https://bcdn.docswell.com/page/4JZPQX5X73.jpg)

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


# Page. 27

![Page Image](https://bcdn.docswell.com/page/YE6M649PJV.jpg)

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


# Page. 28

![Page Image](https://bcdn.docswell.com/page/GE5Z6QNP74.jpg)

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


# Page. 29

![Page Image](https://bcdn.docswell.com/page/972RMP5ZER.jpg)

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