Declarative Automation Bundlesが直接配備へ自動移行

Databricksは、Declarative Automation Bundlesの配備エンジンをTerraformから直接配備へ切り替え始めました。

要点

• ワークスペース上で作成するBundleは2026年7月24日から直接配備が既定です。
• Terraformを使う既存Bundleも自動移行の対象です。
• Databricks CLIの既定変更は2026年8月26日に始まり、Terraformエンジンは最終的に無効化されます。

今回の更新で変わること

ワークスペース上で作成・実行するDeclarative Automation Bundlesは、2026年7月24日から直接配備エンジンを既定で使います。これは単なる将来予告ではなく、記事公開日時点で始まった既定値変更です。Terraformエンジンを使い続けている既存Bundleについても、自動移行が発生します。ワークスペース画面からBundleを扱うチームは、すでに配備経路が変わり得る状態として確認する必要があります。

Databricks CLI側の既定変更は2026年8月26日に始まります。CI/CDでCLIを固定している環境は、ワークスペース上の操作と自動配備で切り替わる時期が異なる点に注意が必要です。同じBundle定義でも、誰がどの経路から実行したかによってTerraformまたは直接配備を通る移行期間が生じます。実行ログにはCLI版、配備エンジン、対象ワークスペースを残し、結果を比較できるようにします。

直接配備はTerraformを介さず、DatabricksのAPIを使ってBundleリソースを配備します。公式告知では、Terraformエンジンは最終的に無効化されるため、旧方式へ恒久的に固定する前提では計画できません。代表的なBundleで、新規作成、既存ジョブやパイプラインの更新、権限変更、削除、失敗後の再実行を試します。とくに自動移行後の最初の配備では、既存リソースが新規作成扱いにならないか、意図しない置き換えや権限差がないかを配備前後で確認しておきたいです。

複数環境がある場合は、開発、検証、本番の順に同じBundleを適用し、差分と所要時間を記録します。CI/CDは8月26日より前に直接配備を明示して試し、切り替え日に初めて新経路を通る状態を避けます。Terraform固有の状態ファイルや診断手順に依存している運用があれば、直接配備で利用できるログと復旧手順へ更新します。今回の変更は選択肢追加ではなく既定経路の移行であり、7月24日と8月26日の二段階の日程、自動移行、最終的なTerraform無効化を一つの移行計画として扱う必要があります。

関係しそうなチーム

Databricksの環境をコードで管理する基盤担当、継続的配備を運用する開発チームに関係します。

実務で確認したいポイント

1. 7月24日以降にワークスペースから実行したBundleの配備エンジンを確認します。
2. 8月26日までにCI/CDのCLI経路を直接配備で回帰試験します。
3. 自動移行される既存BundleとTerraform依存の運用手順を洗い出します。

結局、この更新をどう読むべきか

すでに始まったワークスペース側の切り替えと、8月26日に始まるCLI側の切り替えを分けて管理する必要があります。Terraformへ戻せることを前提にせず、自動移行後の状態と直接配備の回帰試験を早めに確認したい更新です。