Associate 学習教材 ⑦ CI/CD

Databricks 公式ドキュメント（日本語版）の内容を、重要用語・概念を漏らさずまとめた自習用教材です。この md だけで学習が完結することを目指しています。参照した公式ページ:
Databricks Asset Bundles（バンドル構成の例）: https://docs.databricks.com/aws/ja/dev-tools/bundles/examples
宣言型オートメーションバンドルとは（バンドル概要）: https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/bundles/
宣言型オートメーションバンドルの開発（ライフサイクル）: https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/bundles/work-tasks
Azure Databricks Git フォルダー（概要）: https://learn.microsoft.com/ja-jp/azure/databricks/repos/
Git フォルダーの概念: https://learn.microsoft.com/ja-jp/azure/databricks/repos/git-folders-concepts
Git フォルダーの作成と管理（Git 操作）: https://learn.microsoft.com/ja-jp/azure/databricks/repos/git-operations-with-repos
Git フォルダーの Git 統合を構成する（資格情報・ネットワーク・セキュリティ）: https://learn.microsoft.com/ja-jp/azure/databricks/repos/repos-setup
Databricks CLI（概要）: https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/cli/
Databricks CLI のインストールまたは更新: https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/cli/install
Databricks CLI の認証: https://learn.microsoft.com/ja-jp/azure/databricks/dev-tools/cli/authentication

1. このセクションの概要

CI/CD（継続的インテグレーション／継続的デリバリー、Continuous Integration / Continuous Delivery）とは、コードの統合・テスト・デプロイを自動化するソフトウェアエンジニアリングのプラクティスです。Databricks では、データ／AI プロジェクトに対してこのプラクティスを持ち込むための仕組みが用意されています。

このセクションでは、Databricks における CI/CD を支える 3 つの柱を学びます。

Databricks Asset Bundles（DAB）／宣言型オートメーションバンドル（Declarative Automation Bundle）
- ジョブやパイプラインなどの Databricks リソースを コード（YAML）として宣言的に管理 する、IaC（Infrastructure as Code、コードとしてのインフラストラクチャ）的な仕組み。CI/CD の中核。
Git フォルダー（Git folders、旧称 Repos）
- ワークスペース内に Git リポジトリを統合する、ビジュアルな Git クライアント（visual Git client）と API。対話的な開発（interactive development）とバージョン管理に使う。
Databricks CLI（コマンドラインインターフェイス、Command Line Interface）
- ローカルターミナルや自動化スクリプトから Databricks を操作するツール。Databricks REST API をラップしており、バンドルのデプロイもこの CLI 経由で行う。

重要な使い分け（公式の推奨）:

対話的な開発には Git フォルダー を使う。
CI/CD と本番（プロダクション）環境のデプロイには、バージョン管理された成果物とワークロード ID フェデレーションを用いた 宣言型オートメーションバンドル（DAB） を使う。

2. 重要用語集

用語（日本語）	English	説明
CI/CD（継続的インテグレーション／継続的デリバリー）	Continuous Integration / Continuous Delivery	コードの統合・テスト・デプロイを自動化する開発プラクティス。
コードとしてのインフラストラクチャ	Infrastructure as Code (IaC)	インフラ・リソースをコード（宣言的定義）で管理する手法。バンドルはこのアプローチ。
Databricks Asset Bundles（DAB）／宣言型オートメーションバンドル	Declarative Automation Bundle（旧: Databricks Asset Bundles）	Databricks リソース（ジョブ・パイプライン等）を YAML でコード管理し、検証・デプロイ・実行する仕組み。Databricks CLI の機能。
バンドル	bundle	プロジェクトのソースファイル、リソース定義、構成をまとめた「プロジェクトのエンドツーエンドの定義」。1 つのバンドルとしてターゲット環境にデプロイされる。
バンドル構成ファイル	bundle configuration file	バンドルのメタデータを定義する YAML ファイル。
databricks.yml	databricks.yml	バンドルのルートにある必須かつ唯一のメイン構成ファイル。追加ファイルは `include` で参照。
リソース定義	resources	ジョブ、パイプライン、ダッシュボード、モデル、ボリューム等の Databricks リソースを定義するマッピング。
ターゲット	targets	デプロイ先環境（dev / staging / prod など）ごとの設定。`mode` で開発／本番を切り替え。
デプロイターゲット	deployment target	バンドルを配置するワークスペース環境。
開発モード	development mode（`mode: development`）	個人開発ワークスペース向け。テスト用途。
本番モード	production mode（`mode: production`）	本番デプロイ向け。権限・ロック動作が厳格になる。
成果物	artifacts	JAR、Python wheel（whl）など、ビルド／コンパイルの対象物。
変数	variables	バンドル内で再利用する値。`${var.名前}` で参照。
デプロイ	deploy	ローカルのバンドルをリモートワークスペースに配置する操作（`databricks bundle deploy`）。
Git フォルダー（旧 Repos）	Git folders (formerly Repos)	ワークスペース内に Git リポジトリを統合するビジュアル Git クライアントと API。
Git プロバイダー	Git provider	Git リポジトリをホストするサービス（GitHub, GitLab, Azure DevOps, Bitbucket 等）。
クローン（複製）	clone	リモートリポジトリの内容をワークスペースの Git フォルダーとして取得する操作。
コミット	commit	変更をブランチに記録する操作。
プッシュ	push	ローカルのコミットをリモート Git リポジトリへ送る操作。
プル	pull	リモートの最新変更を取り込む操作。
ブランチ	branch	独立した開発ラインを表す Git の分岐。
マージ	merge	あるブランチのコミット履歴を別ブランチに結合（`git merge`）。
リベース	rebase	ターゲットブランチの上にコミットを再適用し線形履歴を作る（`git rebase`）。履歴を書き換える。
リセット	reset	ブランチ内容・履歴を別ブランチの最新状態に置換（`git reset --hard` + `git push --force` 相当）。
マージ競合	merge conflict	同じ行の変更を Git が自動調整できないときに発生する衝突。
スパースチェックアウト	sparse checkout	リポジトリのディレクトリのサブセットだけを複製するクライアント側設定。円錐パターン（cone patterns）を使用。
個人用アクセストークン	Personal Access Token (PAT)	Git プロバイダーや Databricks で認証に使うトークン。
Git 資格情報	Git credentials	Databricks が Git プロバイダーへ認証するための情報（PAT または OAuth）。
Databricks CLI	Databricks CLI	ローカル／自動化から Databricks を操作するコマンドラインツール。REST API をラップ。
構成プロファイル	configuration profile	`.databrickscfg` 内に名前付きで保存される認証設定の単位。
.databrickscfg	.databrickscfg	構成プロファイルを保存するファイル（既定はホームディレクトリ）。
DEFAULT プロファイル	DEFAULT profile	プロファイル未指定時に使われる既定プロファイル。
OAuth U2M 認証	OAuth user-to-machine authentication	対話的にログインして短命トークンを使う認証（推奨）。
OAuth M2M 認証	OAuth machine-to-machine authentication	サービスプリンシパルを使う非対話認証（自動化向け）。
サービスプリンシパル	service principal	自動化・非対話処理のための ID。
REST API	REST API	Databricks を操作する HTTP エンドポイント群。CLI はこれをラップ。
ワークスペースファイル	workspace files	ワークスペース内の非ノートブックファイル。バンドル利用に必要（Databricks Runtime 11.2 以降で既定有効）。

3. 詳細解説

3-1. Databricks Asset Bundles とは（IaC 的にジョブ/パイプラインをコード管理）

Databricks Asset Bundles（DAB、日本語ドキュメントでの新名称は「宣言型オートメーションバンドル（Declarative Automation Bundle）」） は、ソフトウェアエンジニアリングのベストプラクティス（ソース管理、コードレビュー、テスト、CI/CD）を、データ／AI プロジェクトに導入するためのツールです。

バンドル（bundle）とは何か

バンドルは「プロジェクトのエンドツーエンドの定義」で、以下をまとめて 1 つの単位としてターゲット環境にデプロイします。

必要なクラウドインフラストラクチャとワークスペースの構成
ビジネスロジックを含むソースファイル（ノートブック、Python ファイルなど）
Databricks リソースの定義と設定（Lakeflow ジョブ、Lakeflow パイプライン、ダッシュボード、モデルサービングエンドポイント、MLflow 実験、MLflow 登録済みモデルなど）
単体テスト（unit test）と統合テスト（integration test）

IaC（コードとしてのインフラストラクチャ）としての位置づけ

バンドルは、ソースコードと一緒に作成・管理する YAML テンプレートとファイル で定義・管理されるため、IaC が適したシナリオにうまくマッピングされます。

バンドルを使うべきシナリオ

複数の共同作成者（collaborator）と自動化が不可欠で、CI/CD が必要な複雑なプロジェクト。
チームベースの環境でのデータ・分析・ML プロジェクト開発（ソースファイルの整理・管理）。
ML の問題を高速に反復（トレーニング、バッチ推論ジョブなどのパイプラインリソース管理）。
カスタムバンドルテンプレートで組織標準（既定の権限、サービスプリンシパル、CI/CD 構成）を設定。
規制コンプライアンス（コードとインフラのバージョン管理された履歴を保持）。

バンドルのしくみ

バンドルメタデータは、成果物・リソース・構成を指定する YAML ファイル で定義する。
Databricks CLI を使って、その YAML でバンドルを 検証（validate）・デプロイ（deploy）・実行（run） する。
IDE、ターミナル、または Databricks 内から直接バンドルプロジェクトを実行できる。
バンドルは手動で作成することも、テンプレート（template） に基づいて作成することもできる。CLI に単純なユースケース向けの既定テンプレートが同梱されている。

バンドル利用の前提（何をインストールするか）

バンドルは Databricks CLI の機能。ローカルでバンドルをビルドし、CLI でリモートワークスペースにデプロイ・実行する。
リモートワークスペースで ワークスペースファイル（workspace files）が有効 である必要がある（Databricks Runtime 11.2 以降は既定で有効）。
Databricks CLI v0.218.0 以降 をインストールする必要がある（databricks --version で確認）。
Databricks へのアクセスを CLI で構成しておく。推奨は OAuth U2M（ユーザーからマシンへの）認証。
注: ワークスペース内でバンドルを「使うだけ」なら CLI のインストールは不要（ワークスペースのバンドルでの共同作業）。

3-2. bundle の構造（databricks.yml、resources、targets）とデプロイの流れ

databricks.yml のトップレベルマッピング

バンドルには databricks.yml という名前の構成ファイルが少なくとも 1 つ（かつ唯一） 必要です。追加の構成ファイルは databricks.yml の include マッピングで参照します。主なトップレベルキーは次のとおりです。

yaml

bundle:            # バンドルの識別子（name など）
  name: <バンドル名>

workspace:         # ワークスペースの詳細
  host: <ワークスペースURL>
  artifact_path: <アーティファクト保存先パス>

artifacts:         # ビルド／コンパイル対象物（JAR, whl など）
  ...

resources:         # ジョブ・パイプライン等のリソース定義
  ...

targets:           # 環境別（dev/prod 等）の設定
  ...

variables:         # 変数定義
  ...

include:           # 追加構成ファイルの参照
  ...

リソース（resources）

構成できる主なリソースタイプ:

リソース	説明
jobs（ジョブ）	ワークフロー実行単位。タスク、スケジュール、パラメーターを設定可能。
pipelines（パイプライン）	データ処理パイプライン。`serverless: true` でサーバーレス実行。
dashboards（ダッシュボード）	ビジュアライゼーション。データセットのカタログ／スキーマでパラメーター化。
clusters（クラスター）	コンピュートリソース（All-Purpose / Job / Serverless）。
models（モデル）	ML モデル。Unity Catalog に統合。
volumes（ボリューム）	ストレージ。Unity Catalog（UC）統合。

リソースキー（resource key）: リソースの YAML ブロックの最上位要素。databricks bundle run <キー> の対象になる。

ターゲット（targets）

異なる環境でのデプロイ・実行を管理します。mode で挙動が変わります。

yaml

targets:
  dev:
    mode: development       # 開発モード（テスト用途、個人開発ワークスペース向け）
    workspace:
      host: https://dev.cloud.databricks.com
    variables:
      catalog_name: dev_catalog

  prod:
    mode: production        # 本番モード（権限・ロック動作が厳格）
    workspace:
      root_path: /Workspace/Users/.../.bundle/...
    permissions:            # アクセス権限設定
      - user_name: user@example.com
        level: CAN_MANAGE

mode は development または production。デプロイ時の権限・ロック動作に影響する。
一般に、まず個人開発ワークスペース（dev）へデプロイしてテスト → ステージング（staging） → 本番（prod）へデプロイする。
databricks bundle run で -t（--target）を指定しない場合、構成ファイルで宣言された 既定のターゲット が使われる。

成果物（artifacts）

JAR や Python wheel（whl）などをビルドし、デプロイ時にアップロードします。

yaml

artifacts:
  my_java_code:
    type: jar
    path: ./sample-java
    build: 'javac PrintArgs.java && jar cvfm PrintArgs.jar'
    files:
      - source: ./sample-java/PrintArgs.jar

  my_custom_wheel:
    type: whl
    build: poetry build
    path: ./my_custom_wheel

Unity Catalog のボリュームを artifact_path（例: /Volumes/main/default/my_volume）に指定すると、JAR / wheel が自動的に UC ボリュームへアップロードされる。

変数とテンプレート参照

yaml

variables:
  warehouse_id:
    description: Warehouse 指定
    default: baf79a9e4ze90f02

主なテンプレート参照（substitution）:

${var.warehouse_id} : 変数参照
${workspace.current_user.short_name} : ワークスペースの現在ユーザー情報
${resources.pipelines.my_pipeline.id} : リソース ID 参照
${bundle.name} / ${bundle.environment} : バンドル名・環境

デプロイの流れ（バンドルのライフサイクル）

公式が定義するライフサイクルは次の 6 段階です。

作成（スケルトン生成）: プロジェクトに基づいてバンドルの骨組みを作る。
開発（ローカル）: databricks.yml とリソース構成でインフラ・ワークスペース設定・リソース・ソースファイルを定義。
検証（validate）: 構成の設定とリソース定義をオブジェクトスキーマに照らして検証し、デプロイ可能か確認。
デプロイ（deploy）: ターゲットワークスペースへ配置。まず個人開発ワークスペース → ステージング → 本番の順が一般的。
実行（run）: デプロイ済みバンドルで定義したジョブ・パイプラインを実行。
破棄（destroy）: 使わなくなったら、デプロイ済みのジョブ・パイプライン・成果物を完全に削除（元に戻せない）。

バンドルの一意性: バンドルの一意な ID は「名前（name）」「ターゲット（target）」「デプロイ元の ID」で決まる。これらが同一だと別バンドルのデプロイが互いに干渉する。

BUNDLE_ROOT: 環境変数 BUNDLE_ROOT を設定すると、バンドルルート外から databricks bundle コマンドを実行できる。未設定なら現在の作業ディレクトリからバンドルルートを探索する。

3-3. Git フォルダー（旧 Repos）での Git 連携（対応操作・ブランチ運用）

Git フォルダーとは

Git フォルダー（Git folders、旧称 Repos） は、ワークスペース内に Git リポジトリを統合する ビジュアル Git クライアント（visual Git client）と API です。ノートブックやファイルのコードを開発しながら、バージョン管理・コラボレーション・CI/CD にソフトウェア開発のベストプラクティスを適用できます。

Git フォルダーでできること:

リモート Git リポジトリの 複製（clone）・プッシュ（push）・プル（pull）
ブランチ（branch） の作成・管理、マージ（merge）・リベース（rebase）・競合解決（conflict resolution）
ノートブック（IPYNB を含む）やその他ファイルの作成・編集
コミット時の差分（diff）の視覚的比較、マージ競合の解決
Git ディレクトリ API（Repos API） による CI/CD パイプラインとの統合（ワークスペース Git フォルダーをプログラムで最新化するなど）

サポートされている Git プロバイダー

クラウド（SaaS）:

GitHub、GitHub Advanced Enterprise、GitHub Enterprise Cloud
Atlassian Bitbucket Cloud
GitLab、GitLab Enterprise Edition
Microsoft Azure DevOps（Azure Repos）

オンプレミス（自己管理 / Self-Managed）:

GitHub Enterprise Server
Atlassian Bitbucket Server / Data Center
GitLab セルフマネージド
Microsoft Azure DevOps Server（URL が dev.azure.com/* または visualstudio.com/* に一致しない場合、URL ドメインプレフィックスを許可リストへ明示追加が必要）

補足: クラウド（SaaS）とオンプレミス（"Server" / "Self-Managed"）の違いを理解して選ぶ。オンプレミスがインターネットからアクセスできない場合は、VPN 内に Git 認証要求のプロキシ（Git proxy）を設置する必要がある。一覧にないクラウドプロバイダーは GitHub を選ぶとフォールバックとして機能することがある（保証はされない）。

リポジトリのクローン（複製）

親フォルダーに対する CAN MANAGE アクセス許可が必要。
ワークスペースに Git 資格情報（Git credentials） が構成されている必要がある（パブリックリポジトリの読み取りのみなら資格情報なしでも可）。

UI から複製する手順:

サイドバーで ワークスペース を選択し、クローン先フォルダーを参照。
作成 > Git フォルダー をクリック。
ダイアログで以下を指定:
- Git リポジトリ URL（https://example.com/organization/project.git 形式）
- Git プロバイダー
- Git フォルダー名（ワークスペース内のフォルダー名）
- スパースチェックアウトモード（サイズ制限を超える場合などに使用）
Git フォルダーの作成 をクリック。

Web ターミナル（web terminal）から複製する:

bash

cd /Workspace/Users/<your-email>/<project>
git clone <remote-url>

git clone はワークスペースに構成された Git 資格情報を使う。

Git ダイアログの主な操作

ノートブック名の横のブランチボタン、または Git フォルダー名の横の Git ボタンからフルスクリーンのダイアログを開く。ここでできること:

現在の作業ブランチの表示・切り替え
新しいブランチの作成
現在ブランチのファイル資産・サブフォルダーの表示
ブランチ履歴の表示
リモートからのプル
コミットメッセージ（と任意の詳細説明）の追加
コミット & プッシュ（作業ブランチにコミットし、リモートへプッシュ）

ケバブ（kebab）メニューから、ハードリセット・マージ・リベースなどの追加操作を選択できる。

新しいブランチの作成 / 切り替え

作成: Git ダイアログ → Create Branch → 名前とベースブランチを指定 → Create。
切り替え: ブランチのドロップダウンで選択。コミットされていない変更が新ブランチと競合しなければ引き継がれる。
注意: ブランチ切り替えでワークスペース資産が削除される可能性 がある（新ブランチにその資産が無い場合）。元のブランチに戻すと新しい ID / URL で再作成され、この変更は元に戻せない。共有・ブックマークした資産がある場合は切り替え前に確認する。
ローカルブランチは、リモートブランチ削除後も最大 30 日間 Git フォルダーに残る。完全に消すにはリポジトリを削除する。

変更のコミット & プッシュ

ファイルを変更すると UI がハイライト表示。コミットメッセージを入力し コミット & プッシュ でリモートへ反映。
既定ブランチへのコミット権限が無い場合は、新ブランチを作り、Git プロバイダー側で pull request（プルリクエスト） を作成して既定ブランチへマージする。
ノートブックがソースファイル形式（.py, .scala, .sql, .r）の場合、ノートブックの出力（output）は既定でコミットに含まれない。出力を含めるには IPYNB 形式を使う。

変更のプル

Git ダイアログのプルでリモートの最新版に更新。ローカル変更と競合したらマージ競合を解決する。
注意: アップストリームの変更をプルするとノートブックの状態（state）がリセットされる。

マージ / リベース / リセット

マージ（merge）: git merge でコミット履歴を結合。Databricks は初心者にはリベースよりマージを推奨（強制プッシュ不要、履歴を書き換えない）。競合なければ git push でリモートへ。
リベース（rebase）: git rebase でターゲットブランチ上にコミットを再適用し線形履歴を作る。リベース後は git commit と git push --force が必要。履歴を書き換える ため、共同作業者にバージョン管理の問題を起こしうる。
リセット（reset）: UI からの Git リセットは git reset --hard + git push --force に相当。ブランチの内容・履歴を別ブランチの最新状態に置換。ローカル・リモート両方のコミット済み／未コミットの変更がすべて失われる。

マージ競合の解決

プル・リベース・マージ中に、同じ行の変更を Git が自動調整できないと マージ競合（merge conflict） が発生。
Git フォルダー UI で解決: ファイルを手動編集、または「現在のすべての変更を保持」「すべての受信変更を受け取る」を選択、または操作を中止。
手動解決では、残す行を選び、それ以外（Git マージ競合マーカーを含む）を削除 → 解決済みとしてマーク → マージの続行 / リベースの続行。間違えたら 中止（Abort） で元に戻せる。

スパースチェックアウト（sparse checkout）

リポジトリのディレクトリの サブセットだけ を複製するクライアント側設定。リポジトリがサイズ制限を超える場合に有用。
円錐パターン（cone patterns） で対象を指定。複数パターンは改行で区切る。
- パターン未指定 → 既定の円錐パターン（ルート直下のファイルのみ、サブディレクトリなし）。
- parent/child/grandchild を指定 → grandchild 配下すべてに加え、/parent・/parent/child・ルート直下ファイルを含む。
- 除外動作（!）は サポートされない。
クローン時にのみ有効化でき、一度有効化すると無効化できない。作成後は設定 > Advanced > Cone パターンで編集可能。
制限: 4 GB を超える Azure DevOps リポジトリではスパースチェックアウトが機能しない。

Git CLI アクセス（パブリックプレビュー）

Git CLI アクセス権を持つ Git フォルダーでは、ノートブック・Web ターミナル・Genie Code から サーバーレスコンピュート上で標準の Git コマンド を実行できる。

任意の Git コマンド（git stash, git push --force, git rebase -i など）が使える。
事前コミットフック（pre-commit hook）で linting・コードスキャンを統合可能。
標準 Git フォルダーの 2 GB メモリ / 4 GB ディスク制限を超えるリポジトリを扱える。
Git サブモジュール（submodule）や Large File Storage（LFS）を使える。
Web ターミナルから複製したフォルダーは常に Git CLI アクセス権を持つ。UI から作成したフォルダーは、ワークスペースが対象（プレビュー有効・サーバーレス利用可・プロバイダーへ到達可・10,000 ファイル以下）の場合に自動付与される。
制限: Git URL 許可リストは UI 操作にのみ適用され CLI 直接実行には適用されない。CLI アクセス権を持つフォルダーは List Repos API に返らない。

Git フォルダーでの共同作業（コラボレーション）

各チームメンバーが 自分専用の Git フォルダー を持ち、自分の開発ブランチで作業する。
1 つの Git フォルダーで Git 操作を行うのは 1 人だけにする（複数人だと、誰かが全員のブランチを意図せず切り替えるなどの問題が起こる）。
構成を共有するには 共有 > コピーリンク で URL を送り、相手が開くと事前設定済みダイアログから自分のワークスペースに複製できる。

3-4. Git フォルダーの Git 統合構成（資格情報・認証・ネットワーク・セキュリティ）

前提条件

Git フォルダーがワークスペースで有効（既定で有効）。
Git プロバイダーアカウント（GitHub, GitLab, Azure DevOps, Bitbucket, または AWS CodeCommit）を持つ。
プライベートリポジトリまたは書き込み操作には、Git プロバイダーの 個人用アクセストークン（PAT, Personal Access Token） または OAuth 資格情報が必要。パブリックリポジトリの読み取りだけなら資格情報不要。

Git 資格情報の追加

上部バーのユーザー名 → Settings（設定）。
リンクされたアカウント（Linked accounts） をクリック。
Git 資格情報の追加 をクリック。
ドロップダウンから Git プロバイダー を選択（OAuth リンクを提供するプロバイダーもあれば、PAT が必要なプロバイダーもある）。
メール（email） を入力。
トークン（token） フィールドに PAT を貼り付け（GitHub で SAML SSO が有効なら PAT を SSO 認証する）。
保存。

Databricks Repos API でも Git 資格情報を管理できる。

複数の Git 資格情報 / 既定の資格情報

各ユーザーは複数の Git 資格情報を保存でき、プロバイダー／アカウントを切り替えずに使える。各ユーザー最大 10 個 まで。
各 Git フォルダーで、Git 設定タブから使用する資格情報を選択できる。
既定の資格情報（default credentials）: 各 Git プロバイダーにつきユーザーごとに 1 つ。ジョブ、Repos API 操作、特定資格情報未選択の Git フォルダー操作で自動使用される。プロバイダー用に最初に作った資格情報が自動的に既定になる。
既定以外の資格情報を要するジョブは サービスプリンシパル を使う必要がある。Databricks GitHub アプリはリンク資格情報を 1 つだけ許可。

Azure DevOps 特有

既定では、トークン／アプリパスワードを入れなければ Microsoft Entra ID トークン を使用。Azure DevOps 個人用アクセストークンを指定するとそちらを使う。
Azure パスワード更新後は Databricks で再認証すること（そうしないと接続検証に最大 24 時間かかることがある）。

Git コミットのアイデンティティ

メール（email） → すべてのコミットの作成者メール（GIT_AUTHOR_EMAIL / GIT_COMMITTER_EMAIL）。
ユーザー名（username） → コミッター名（GIT_AUTHOR_NAME / GIT_COMMITTER_NAME）。
メール未指定だと Git ユーザー名がメールとして使われ、コミットの適切な帰属（attribution）が妨げられることがある。

ネットワーク接続

Git フォルダーは Git プロバイダーへのネットワーク接続が必要。多くはインターネット経由で追加設定なしに動作。
追加構成が必要なケース: Git プロバイダーの IP 許可リスト（IP allow list）、セルフホスト Git サーバー、プライベートネットワークホスティング。
IP 許可リスト: リージョンの Databricks コントロールプレーンの NAT IP アドレスを Git サーバーの IP 許可リストに追加する。
プライベート Git サーバー / サーバーレス: プライベートエンドポイント規則を使うネットワーク接続構成（NCC, Network Connectivity Configuration）を設定する。

セキュリティ機能

Git 資格情報の暗号化: Azure Key Vault でカスタマーマネージドキー（CMK, customer-managed keys）を使い PAT 等を暗号化。
Git URL 許可リスト（allow list）: ワークスペース管理者がアクセス可能なリモートリポジトリを制限し、コード流出を防止。設定オプション:
- 無効（制限なし）
- クローン・コミット・プッシュを許可リスト URL に制限
- コミットとプッシュのみ制限（クローン・プルは無制限）
- プレフィックス一致（大文字小文字を区別しない）で判定。ワイルドカード不可。例: https://github.com, https://github.com/CompanyName, https://dev.azure.com/CompanyName。ユーザー名やトークンを含む URL は入れない。保存で既存リストを上書きし、反映に最大 15 分。
- Azure DevOps で Microsoft Entra ID 認証を使う場合、既定許可リストは dev.azure.com と visualstudio.com に制限。
アクセス制御（access control）: Premium プランのみ。Git フォルダーのアクセス許可レベル:
- NO PERMISSIONS: アクセス不可
- CAN READ: 表示のみ
- CAN RUN: 表示と実行
- CAN EDIT: 表示・実行・変更
- CAN MANAGE: 共有・削除を含むフルコントロール
監査ログ（audit logs）: Git フォルダーの作成・更新・削除、一覧表示、リモートとの同期を記録。
シークレット検出（secret detection）: コミット前に公開資格情報を自動スキャン（例: AKIA で始まる AWS アクセスキー ID などを検出して警告）。

3-5. Databricks CLI の基礎（インストール・認証・主要コマンド）

Databricks CLI とは / しくみ

Databricks CLI（コマンドラインインターフェイス） は、ローカルターミナルや自動化スクリプト、あるいは Web ターミナルから Databricks プラットフォームを操作するツール。
CLI は Databricks REST API をラップ している。REST API は、アカウントやワークスペースのオブジェクト情報を変更・要求するエンドポイントを提供する。
例: 次の 2 つは等価。

bash

databricks clusters get 1234-567890-a12bcde3

bash

curl --request GET "https://${DATABRICKS_HOST}/api/2.0/clusters/get" \
     --header "Authorization: Bearer ${DATABRICKS_TOKEN}" \
     --data '{ "cluster_id": "1234-567890-a12bcde3" }'

利用可能な CLI コマンドグループ（command group）を見るには databricks -h。

CLI のバージョン（リリースの種類）

v1.0.0 以降: 一般公開（GA, Generally Available）。
v0.205 〜 0.299: パブリックプレビュー（Public Preview）。
v0.18 以降: レガシ CLI（legacy CLI）。新機能・サポートの計画なし。v0.18 以前から v0.205 以降への移行が必要。
バンドル利用には v0.218.0 以降 が必要。

インストール（v0.205 以降）

OS	方法
macOS	Homebrew
Linux	curl またはソースビルド
Windows	WinGet、Chocolatey（試験段階）、WSL、またはソースビルド

代表的なコマンド:

bash

# macOS（Homebrew）
brew tap databricks/tap
brew trust databricks/tap        # Homebrew 6.0.0 以降で必要
brew install databricks

# Windows（WinGet）
winget search databricks
winget install Databricks.DatabricksCLI

# Linux / macOS / Windows（curl）
curl -fsSL https://raw.githubusercontent.com/databricks/setup-cli/main/install.sh | sh

# 更新（Homebrew / WinGet / curl）
brew upgrade databricks
winget upgrade Databricks.DatabricksCLI

インストール確認: databricks -v または databricks version。0.205.0 以上 なら成功。
curl 版は macOS/Linux で /usr/local/bin/databricks、Windows で C:\Windows\databricks.exe に配置。
ワークスペース内の Web ターミナル からも CLI を使える。

認証（authentication）

CLI コマンド実行前に、対象のアカウントまたはワークスペースの認証を構成する必要がある。認証は 構成プロファイル（configuration profile） で管理し、.databrickscfg ファイルに保存する。

主な認証タイプ:

OAuth U2M（ユーザーからマシンへの、user-to-machine）認証 ← 対話的開発で推奨
- 対話的にログインし、CLI が短命トークン（1 時間以内に期限切れ）を管理。誤って公開してもリスクが小さい。
- ログイン:
  bash
```
# ワークスペースレベル
databricks auth login --host <workspace-url>
# アカウントレベル
databricks auth login --host <account-console-url> --account-id <account-id>
```
- 完了すると構成プロファイルが保存される。トークンは v1.0.0 以降 OS のセキュアストレージ（macOS キーチェーン、Windows 資格情報マネージャー、Linux D-Bus Secret Service）に格納され、.databrickscfg には非シークレット情報（ホスト名・プロファイル名）のみ保持。
OAuth M2M（マシン間、machine-to-machine）認証 ← 自動化・CI 向け
- サービスプリンシパル（service principal） と OAuth クライアント資格情報フローを使い、対話的サインインなしでアクセス。.databrickscfg に client_id / client_secret を設定。
Azure マネージド ID 認証（azure_use_msi = true、azure_client_id）
Microsoft Entra ID サービスプリンシパル認証（azure_tenant_id / azure_client_id / azure_client_secret）
Azure CLI 認証（az login でサインイン後、host を指定）
個人用アクセストークン（PAT）認証（レガシ）: Databricks の PAT を使う。OAuth の方が安全なため、可能な限り OAuth を推奨。

.databrickscfg（構成プロファイル）の例:

ini

# ワークスペースレベル・OAuth M2M の例
[<some-unique-configuration-profile-name>]
host          = <workspace-url>
client_id     = <service-principal-client-id>
client_secret = <service-principal-oauth-secret>

プロファイルの使い方:

CLI コマンドに --profile または -p フラグでプロファイル名を渡す。

bash

databricks clusters list -p <profile-name>
databricks account groups list -p <profile-name>

--profile / -p の後で Tab キー を押すと、利用可能なプロファイル一覧が表示される。
プロファイル名を指定しない場合は DEFAULT プロファイル が使われる。

認証設定の評価順序（優先順位）:

CLI は認証時、次の順で設定を探し、見つかった時点で探索を停止する。

バンドル設定ファイル（バンドル作業ディレクトリから実行時。ただし資格情報の値を直接含めることはできない）
環境変数（DATABRICKS_HOST, DATABRICKS_TOKEN など）
.databrickscfg 内の構成プロファイル

例: DATABRICKS_TOKEN が設定されていれば、.databrickscfg に複数トークンがあってもそれが使われる。

プレーンテキストフォールバック: OS セキュアストレージが使えない環境（ヘッドレスサーバー、CI 環境）では、DATABRICKS_AUTH_STORAGE=plaintext 環境変数、または .databrickscfg の [__settings__] セクションに auth_storage = plaintext を設定して JSON ファイルにトークンを保存できる（環境変数が構成より優先）。

主要な CLI コマンド（バンドル関連）

コマンド	説明
`databricks bundle init`	テンプレートから新規バンドルプロジェクトを作成。既定テンプレートの選択と変数入力を対話的に行う。
`databricks bundle init <path-or-url>`	ローカルパス／リモート URL のカスタムテンプレートから作成。
`databricks bundle schema`	バンドル構成の JSON スキーマを出力（IDE の補完・検証に利用）。
`databricks bundle validate`	バンドル構成をスキーマに照らして検証。成功時にバンドル ID の要約を返す。
`databricks bundle deploy`	バンドルを構成で宣言されたターゲットワークスペースへデプロイ。
`databricks bundle run <key>`	デプロイ済みのジョブ／パイプラインをキー指定で実行。`-t <target>` でターゲット指定。
`databricks bundle generate`	ワークスペース内の既存リソースからバンドル構成を自動生成。
`databricks bundle deployment bind`	バンドル構成をワークスペース内リソースにリンクして同期。
`databricks bundle destroy`	デプロイ済みのジョブ・パイプライン・成果物を完全削除（`--auto-approve` で確認スキップ）。
`databricks -h` / `databricks -v` / `databricks version`	ヘルプ表示 / バージョン確認。

4. 構文・コード例

databricks.yml の例（ジョブ + ターゲット）

yaml

bundle:
  name: hello_bundle

resources:
  jobs:
    hello_job:
      name: hello-job
      tasks:
        - task_key: notebook_task
          notebook_task:
            notebook_path: ./src/hello.ipynb

targets:
  dev:
    mode: development
    default: true
    workspace:
      host: https://dev.cloud.databricks.com
  prod:
    mode: production
    workspace:
      host: https://prod.cloud.databricks.com
    permissions:
      - user_name: user@example.com
        level: CAN_MANAGE

サーバーレスジョブ / パラメーター / スケジュール

yaml

resources:
  jobs:
    serverless_job:
      tasks:
        - task_key: notebook_task
          notebook_task:
            notebook_path: ./notebook.ipynb
      parameters:
        - name: param1
          default: value1
      # Quartz Cron 式（毎日 8 時）
      schedule:
        quartz_cron_expression: '0 0 8 * * ?'
        timezone_id: Asia/Tokyo

実行時にジョブパラメーターを上書き:

bash

databricks bundle run -- --param1=value2

成果物（wheel / jar）とライブラリ

yaml

artifacts:
  my_custom_wheel:
    type: whl
    build: poetry build
    path: ./my_custom_wheel

resources:
  jobs:
    my_job:
      tasks:
        - task_key: main
          libraries:
            - whl: ../dist/*.whl
            - jar: ./PrintArgs.jar
            - requirements: /Workspace/${workspace.file_path}/requirements.txt

バンドルのライフサイクルコマンド（一連の流れ）

bash

# 1. 作成
databricks bundle init

# 2. 検証
databricks bundle validate

# 3. デプロイ（構成で宣言された既定ターゲットへ）
databricks bundle deploy

#   ターゲット指定でデプロイ
databricks bundle deploy -t dev

# 4. 実行
databricks bundle run hello_job
databricks bundle run -t dev hello_job

# 5. 破棄
databricks bundle destroy
databricks bundle destroy --auto-approve

CLI 認証・プロファイル

bash

# OAuth U2M ログイン（ワークスペース）
databricks auth login --host https://<workspace>.cloud.databricks.com

# プロファイルを指定してコマンド実行
databricks clusters list -p DEV
databricks account groups list -p PROD

# バージョン確認
databricks --version

Web ターミナルでの Git 操作（Git CLI アクセス）

bash

cd /Workspace/Users/<your-email>/<project>
git clone <remote-url>

cd my-repo
git checkout -b feature_a      # ブランチ作成
git add .
git commit -m "message"        # コミット
git push                       # プッシュ
git pull                       # プル
git rebase -i main             # 対話的リベース
git stash                      # 退避

5. 試験で問われるポイント

DAB（Databricks Asset Bundles）= 宣言型オートメーションバンドルは、Databricks リソースを YAML（コード）で宣言的に管理 する IaC の仕組みであり、CI/CD の中核であること。旧称が Databricks Asset Bundles であることも押さえる。
databricks.yml はバンドルの 必須かつ唯一 のメイン構成ファイル。トップレベルに bundle / resources / targets / artifacts / variables などを持つ。
targets（ターゲット） で環境（dev / staging / prod）を分け、mode: development / mode: production で挙動（権限・ロック）が変わる。
バンドルのライフサイクル: 作成 → 開発 → 検証（validate）→ デプロイ（deploy）→ 実行（run）→ 破棄（destroy）。それぞれ対応する databricks bundle サブコマンドがある。
バンドルは Databricks CLI の機能。利用には CLI v0.218.0 以降 と、リモートワークスペースで ワークスペースファイルが有効（Runtime 11.2 以降は既定有効）であることが必要。
Git フォルダー（旧 Repos） は 対話的開発・バージョン管理 用のビジュアル Git クライアント。CI/CD・本番デプロイにはバンドルを使う という使い分けが公式推奨。
対応 Git 操作: clone / commit / push / pull / branch / merge / rebase / reset / 競合解決 / スパースチェックアウト。マージは履歴を書き換えず、リベース・リセットは履歴を書き換える（強制プッシュを伴う）。
1 つの Git フォルダーで Git 操作するのは 1 人だけ。各メンバーは自分の Git フォルダー・開発ブランチを持つ（コラボレーションのベストプラクティス）。
ブランチ切り替えでワークスペース資産が削除されうる、プルでノートブックの状態がリセットされる という副作用。
ノートブックがソース形式（.py 等）だと 出力はコミットに含まれない（IPYNB 形式なら含められる）。
Git 連携には Git 資格情報（PAT または OAuth） が必要。パブリックリポジトリの読み取りのみ資格情報不要。各ユーザー最大 10 個、プロバイダーごとに 1 つの既定資格情報。
サポート Git プロバイダー: GitHub / GitLab / Azure DevOps（Azure Repos）/ Bitbucket / AWS CodeCommit（クラウド・オンプレミス両対応）。
Databricks CLI は REST API をラップ している。認証は 構成プロファイル（.databrickscfg） で管理し、-p / --profile で選択、未指定なら DEFAULT。
認証は OAuth（U2M / M2M）が推奨、PAT はレガシ。認証設定の評価順序は バンドル設定 → 環境変数 → .databrickscfg プロファイル。
セキュリティ: Git URL 許可リスト、アクセス制御（CAN READ/RUN/EDIT/MANAGE、Premium プラン）、監査ログ、シークレット検出、カスタマーマネージドキーによる資格情報暗号化。

6. 理解度チェックリスト

[ ] Databricks Asset Bundles（DAB）／宣言型オートメーションバンドルが「何を」「なぜ」実現するか（IaC で Databricks リソースをコード管理し CI/CD を実現）を説明できる
[ ] databricks.yml がバンドルの必須・唯一のメイン構成ファイルであり、bundle / resources / targets / artifacts / variables を持つことを理解している
[ ] resources で定義できる主なリソース（jobs, pipelines, dashboards, clusters, models, volumes）を挙げられる
[ ] targets と mode: development / mode: production の役割の違いを説明できる
[ ] バンドルのライフサイクル（作成→開発→検証→デプロイ→実行→破棄）と対応コマンド（init / validate / deploy / run / destroy）を順に言える
[ ] バンドル利用の前提（CLI v0.218.0 以降、ワークスペースファイル有効、OAuth 認証）を知っている
[ ] Git フォルダー（旧 Repos）が対話的開発・バージョン管理用であり、CI/CD・本番デプロイにはバンドルを使うという使い分けを説明できる
[ ] clone / commit / push / pull / branch / merge / rebase / reset の各操作の意味と、履歴を書き換える操作（rebase, reset）を区別できる
[ ] マージ競合が起きる条件と、Git フォルダー UI での解決手順を説明できる
[ ] スパースチェックアウトと円錐パターンの用途（大規模リポジトリの一部だけ複製）を理解している
[ ] 「1 フォルダー 1 人で Git 操作」「各人が自分の開発ブランチ」というコラボレーションのベストプラクティスを言える
[ ] ブランチ切り替えによる資産削除、プルによるノートブック状態リセットの副作用を認識している
[ ] ノートブックのソース形式（.py 等）では出力がコミットされないこと（IPYNB では含められること）を知っている
[ ] Git 資格情報（PAT / OAuth）が必要な場面と不要な場面（パブリック読み取り）を区別できる
[ ] サポートされる Git プロバイダー（GitHub / GitLab / Azure DevOps / Bitbucket / AWS CodeCommit）を挙げられる
[ ] Git URL 許可リスト、アクセス制御レベル（CAN READ/RUN/EDIT/MANAGE）、監査ログ、シークレット検出などのセキュリティ機能を説明できる
[ ] Databricks CLI が REST API をラップしていることを理解している
[ ] CLI のインストール方法（Homebrew / WinGet / curl）とバージョン確認方法（databricks -v）を知っている
[ ] 構成プロファイル・.databrickscfg・DEFAULT プロファイル・-p / --profile フラグの役割を説明できる
[ ] OAuth U2M / M2M 認証と PAT（レガシ）の違い、認証設定の評価順序（バンドル→環境変数→プロファイル）を説明できる

Associate 学習教材 ⑦ CI/CD ​

1. このセクションの概要 ​

2. 重要用語集 ​

3. 詳細解説 ​

3-1. Databricks Asset Bundles とは（IaC 的にジョブ/パイプラインをコード管理） ​

3-2. bundle の構造（databricks.yml、resources、targets）とデプロイの流れ ​

databricks.yml のトップレベルマッピング ​

リソース（resources） ​

ターゲット（targets） ​

成果物（artifacts） ​

変数とテンプレート参照 ​

デプロイの流れ（バンドルのライフサイクル） ​

3-3. Git フォルダー（旧 Repos）での Git 連携（対応操作・ブランチ運用） ​

Git フォルダーとは ​

サポートされている Git プロバイダー ​

リポジトリのクローン（複製） ​

Git ダイアログの主な操作 ​

新しいブランチの作成 / 切り替え ​

変更のコミット & プッシュ ​

変更のプル ​

マージ / リベース / リセット ​

マージ競合の解決 ​

スパース チェックアウト（sparse checkout） ​

Git CLI アクセス（パブリックプレビュー） ​

Git フォルダーでの共同作業（コラボレーション） ​

3-4. Git フォルダーの Git 統合構成（資格情報・認証・ネットワーク・セキュリティ） ​

前提条件 ​

Git 資格情報の追加 ​

複数の Git 資格情報 / 既定の資格情報 ​

Azure DevOps 特有 ​

Git コミットのアイデンティティ ​

ネットワーク接続 ​

セキュリティ機能 ​

3-5. Databricks CLI の基礎（インストール・認証・主要コマンド） ​

Databricks CLI とは / しくみ ​

CLI のバージョン（リリースの種類） ​

インストール（v0.205 以降） ​

認証（authentication） ​

主要な CLI コマンド（バンドル関連） ​

4. 構文・コード例 ​

databricks.yml の例（ジョブ + ターゲット） ​

サーバーレスジョブ / パラメーター / スケジュール ​

成果物（wheel / jar）とライブラリ ​

バンドルのライフサイクルコマンド（一連の流れ） ​

CLI 認証・プロファイル ​

Web ターミナルでの Git 操作（Git CLI アクセス） ​

5. 試験で問われるポイント ​

6. 理解度チェックリスト ​

Associate 学習教材 ⑦ CI/CD

1. このセクションの概要

2. 重要用語集

3. 詳細解説

3-1. Databricks Asset Bundles とは（IaC 的にジョブ/パイプラインをコード管理）

3-2. bundle の構造（databricks.yml、resources、targets）とデプロイの流れ

databricks.yml のトップレベルマッピング

リソース（resources）

ターゲット（targets）

成果物（artifacts）

変数とテンプレート参照

デプロイの流れ（バンドルのライフサイクル）

3-3. Git フォルダー（旧 Repos）での Git 連携（対応操作・ブランチ運用）

Git フォルダーとは

サポートされている Git プロバイダー

リポジトリのクローン（複製）

Git ダイアログの主な操作

新しいブランチの作成 / 切り替え

変更のコミット & プッシュ

変更のプル

マージ / リベース / リセット

マージ競合の解決

スパースチェックアウト（sparse checkout）

Git CLI アクセス（パブリックプレビュー）

Git フォルダーでの共同作業（コラボレーション）

3-4. Git フォルダーの Git 統合構成（資格情報・認証・ネットワーク・セキュリティ）

前提条件

Git 資格情報の追加

複数の Git 資格情報 / 既定の資格情報

Azure DevOps 特有

Git コミットのアイデンティティ

ネットワーク接続

セキュリティ機能

3-5. Databricks CLI の基礎（インストール・認証・主要コマンド）

Databricks CLI とは / しくみ

CLI のバージョン（リリースの種類）

インストール（v0.205 以降）

認証（authentication）

主要な CLI コマンド（バンドル関連）

4. 構文・コード例

databricks.yml の例（ジョブ + ターゲット）

サーバーレスジョブ / パラメーター / スケジュール

成果物（wheel / jar）とライブラリ

バンドルのライフサイクルコマンド（一連の流れ）

CLI 認証・プロファイル

Web ターミナルでの Git 操作（Git CLI アクセス）

5. 試験で問われるポイント

6. 理解度チェックリスト