Databricks Certified Data Engineer Associate 教科書
第5章 CI/CDの実装(Implementing CI/CD, 10%)
🎯 この節の学習目標
Databricks Git Folders(旧 Databricks Repos)は、ワークスペース内に Git リポジトリのクローンを作成し、ノートブックやソースファイルを Git でバージョン管理するための機能です。かつては「Databricks Repos」という名称でしたが、現在は「Git Folders」に改名されており、機能はそのまま引き継がれています(本書では以降「Git Folders」と表記します)。
Git Folders を使うと、ワークスペースの UI 上から次の Git 操作を直接行えます。
| 操作 | Git Folders(ワークスペース内)でできること |
|---|---|
| クローン | リモートリポジトリをワークスペース内の Git フォルダとして複製する |
| ブランチ作成・切替 | feature ブランチを作成し、作業対象のブランチを UI から切り替える |
| コミット&プッシュ | 変更内容を確認(差分表示)し、コミットメッセージを付けてリモートへ送る |
| プル | リモートの最新変更をワークスペース側へ取り込む |
| マージ競合の解決 | プル時に競合が起きた場合、UI 上で競合箇所を確認して解決できる |
| リセット等 | ローカルの変更を破棄してリモートの状態に合わせる、などの補助操作 |
試験問題では旧称の Databricks Repos のまま出題される可能性があります。「Repos を使ってノートブックをバージョン管理する」「Repo 内でブランチを切り替える」といった表現が出てきても、本節の Git Folders の内容がそのまま対応します。「Repos = Git Folders」という読み替えを覚えておきましょう。
現行の名称は Databricks Git Folders です。ワークスペースのファイルツリー上で「Git フォルダ」として表示され、通常のワークスペースフォルダと同じ場所に並びます。クローン・ブランチ操作・コミット・プッシュ・プル・競合解決といった機能は Repos 時代と同じで、UI の呼び名が変わったと理解すれば十分です。
Git Folders は「日常の Git 操作をワークスペース内で完結させる」機能ですが、すべての Git 機能を持っているわけではありません。この線引きが試験で問われます。
| 作業 | どこで行うか |
|---|---|
| ブランチ作成・切替、コミット、プッシュ、プル、マージ競合の解決 | Git Folders(ワークスペース内 UI) |
| プルリクエスト(PR)の作成・レビュー・マージ承認 | Git プロバイダ側(GitHub、Azure DevOps など) |
| ブランチ保護ルール、マージ条件の設定 | Git プロバイダ側 |
| CI パイプライン(自動テスト・自動デプロイ)の定義と実行 | Git プロバイダ側の CI/CD サービス(GitHub Actions など。5-3 で詳述) |
📝 試験のポイント
「開発者がノートブックの変更をレビューしてもらうためにプルリクエストを作成したい。どこで行うか?」→ 正解は「Git プロバイダ(GitHub 等)の画面で作成する」です。Git Folders の UI に PR 作成機能はありません。逆に「ブランチの切り替え」「コミットとプッシュ」「プルによる最新化」「マージ競合の解決」はワークスペース内の Git Folders で行えます。この役割分担を選択肢の切り分けに使いましょう。
対応する Git プロバイダには GitHub、GitLab、Bitbucket Cloud、Azure DevOps、AWS CodeCommit などがあります。接続には各プロバイダの個人アクセストークン(PAT)や、より安全な連携方式(GitHub App など)を使って、ユーザーごとに Git 資格情報を登録します。
Git Folders を使った標準的な開発ワークフローは次のとおりです。「どの作業がワークスペース側か、プロバイダ側か」を意識しながら追ってください。
feature/add-silver-table)図:Git Folders を起点とした開発〜デプロイの全体像
この図の後半(CI/CD から各環境への展開)を実現する仕組みが、次節以降で学ぶ Declarative Automation Bundles(旧 Databricks Asset Bundles)と Databricks CLI です。5-1 は「コードを安全に main へ届けるまで」、5-2・5-3 は「main のコードを環境へ届ける」と役割を整理して読み進めてください。
Git Folders で作成した Git フォルダの中身は、通常のワークスペースファイルと同じように開いて実行できます。違いは「Git リポジトリと紐づいているかどうか」だけです。Git フォルダ内のノートブックはブランチの状態を反映し、Git フォルダ外のノートブックは Git 管理外です。チーム開発するコードは Git フォルダ内に置くのが原則です。
ノートブックを Git で管理するときのベストプラクティスは、ソースファイル形式(.py や、セル区切りコメント付きのソース)としてコミットすることです。Git Folders はノートブックを既定でソース形式として扱うため、差分レビュー(PR 上での diff 確認)が人間に読みやすい形になります。出力結果(実行結果セル)はコミットに含めないのが原則で、レビューのノイズや機密データの混入を防げます。
💡 具体例:チーム開発での運用ルール
あるデータエンジニアリングチームでは、次のルールで Git Folders を運用しています。
📝 試験のポイント
「複数の開発者が同じコードベースで並行開発したい」→ 正解の方向性は「各自が Git フォルダをクローンし、feature ブランチで作業して PR でマージする」です。「1つのノートブックを全員で直接編集する」「ワークスペースのバージョン履歴機能だけに頼る」といった選択肢は、レビューや再現性の要件を満たせないため誤答側になります。
✅ この節のまとめ
問1. データエンジニアが Databricks Git Folders(旧 Repos)の UI から直接実行できる操作はどれか。
正解:B
Git Folders では、ブランチ作成・切替、コミット、プッシュ、プル、マージ競合の解決をワークスペース UI から行えます。Aのプルリクエストの作成とマージ、Cのブランチ保護は Git プロバイダ(GitHub 等)側の機能です。Dの CI パイプラインもプロバイダ側の CI/CD サービス(GitHub Actions 等)で定義するもので、Git Folders の機能ではありません。
問2. 開発者が feature ブランチでノートブックを修正し、チームのレビューを経て main ブランチへ反映したい。正しい手順の並びはどれか。
正解:B
feature ブランチでの開発 → コミット&プッシュ(Git Folders)→ PR の作成とレビュー・マージ(Git プロバイダ側)という役割分担が正しい流れです。Aは main への直接変更でレビューを経由せず、ブランチ保護にも反します。Cは Git Folders に PR 作成機能がないため実行できません。Dはバージョン管理と監査可能性を放棄した手順で、CI/CD の目的に反します。
問3. Git Folders でリモートの最新変更を取り込むためにプルを実行したところ、自分のローカル変更と競合が発生した。適切な対応はどれか。
正解:B
Git Folders はマージ競合の解決を UI 上でサポートしており、競合箇所を確認して解決したうえで作業を続行できます。Aのような作り直しは不要です(最終手段としてローカル変更の破棄などはありますが「しかない」は誤り)。Cのように競合を放置したままプッシュで自動解決されることはありません。Dはプル自体が Git Folders の基本機能なので誤りです。
問4. ノートブックを Git でバージョン管理する際のベストプラクティスとして最も適切なものはどれか。
正解:A
ソース形式でコミットすると PR 上の差分が読みやすくなり、レビューが機能します。出力セルを含めるBは、差分のノイズが増えるうえ、結果に含まれるデータが機密情報の混入経路にもなるため不適切です。Cのワークスペース履歴は個人の編集履歴としては便利ですが、ブランチ・レビュー・チーム共有といった CI/CD の要件を満たしません。Dのような巨大な一括コミットはレビューと問題の切り分けを困難にします。