LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@jnitin株式会社BeeX

[DevOpsとADF (1) ] ADFにおけるGit構成

Last updated at Posted at 2025-08-17

はじめに

本シリーズでは、Azure DevOpsを使ってAzure DataFactory(以降ADF)をCI/CDできる環境を構築する手順を紹介します。

  • 今回の内容
    • 初回はADFにおけるGit構成について記載します。

ADFでCICD ?

  • 問「ADFのCI/CDのイメージが湧かないです」
    • まずADFでCI/CDを使うにあたり、機能の役割分担を説明します。
      • CI (Continuous Integration)
        • ADFの[Git構成]機能を使い、ADFの設定をJSONのコードとして出力させる
        • 出力された設定ファイル(JSON)はGitリポジトリ(以下いずれかに保存)
          • GitHub
          • Azure DevOps Git
      • CD (Continuous Delivery)
        • Publish操作、またはビルドパイプラインからARMテンプレートが生成される。
        • 生成されたARMテンプレートを使い、各システムランドスケープ(開発/検証/本番)に自動デプロイする
        • リリースパイプライン上では、人間による承認プロセスを設定できる。
      • image.png
      • ADFも設定はJSONですので、プログラムコードのような状態管理や、複数人によるスムーズな開発と安全なデプロイが可能になります。

　

  • 問「なぜADFでCI/CDをやるの？」
    • ADFインスタンスがシステムランドスケープ(開発/検証/本番等)ごとに複数ある場合に、各環境へのデプロイを堅牢化・自動化するにはCI/CDは極めて有効です。
      • 手動で複数のランドスケープに同じ設定を行うとミスが起こりやすいです。
        • CDにより Dev -> Test -> Prod へのデプロイを承認フローを経由した正しいコードで安全に行うことができます。
      • また、ARMテンプレートのエクスポート・インポートも以下のような課題があります。
        • エクスポートしたARMテンプレートの書き換えが必要。
          • factoryName,principalId,tenantId 等パラメータの書き換え
        • インポートはリソースの依存関係により失敗しやすいため、事前に十分なリストアテストが必要。
          • 例としてセルフホステッド統合ランタイムを利用している場合、事前に手動で作成しないと、関係リソース（リンクサービス・データセット・データフロー等）も巻き込まれインポートに失敗する。
    • 他の理由として、CIとしてGit構成を有効化しておくと、自動バックアップの代わりになるという点も大きな利点です。Git利用のため、ある時点でのスナップショット的な設定を追うことができます。

　

  • 問「デメリットはないの？」
    • デメリットが全くないとは言い切れません。以下のように認知負荷が上がります。
      • ADFを操作するのにGitの知識が必要
        • ブランチ・コミット・プルリクエスト・マージ等の理解
        • ADFのパブリッシュまわりの操作感が従来と変わる。
    • CDを行う場合は、AzureDevOpsの学習と環境構築が必要
      • AzureDevOpsは、ADFとは異なるインターフェースとなるため、各種メニューの学習が必要。

　

  • 「将来性は？ Microsoft Fabricに統合されて無駄になるんじゃ？」
    • 2025/7/24時点では、Fabric側にはCI/CD機能は実装されていないため、CI/CDを行う場合はFabric Data Factoryではなく、Azure Data Factoryを使う必要があります。
    • 将来的にADFやAzureDevOpsがどうなるかはわかりませんが、現時点ではADFサービスは継続され、Fabric側が優先的に機能拡張されるようです。
      • https://learn.microsoft.com/ja-jp/fabric/data-factory/migrate-from-azure-data-factory

      • 明確にするために、現在、データ インジェストのために Azure Data Factory または Synapse Gen2 を非推奨にする計画はありません。 エンタープライズ データ インジェスト用の Fabric パイプラインへの投資に重点を置く優先順位があるため、Fabric 容量によって提供される追加の価値は時間の経過と同時に増加します。 Fabric 容量を選択したお客様は、Microsoft Fabric 製品ロードマップとの連携の恩恵を受けることができます。

      • 本日時点でいえば、Fabric Data Factoryの機能はまだ ADFに追いついていない部分があります。

Git構成の選択

ADFではGitリポジトリを以下の２つから選択できます。

  • GitHub
  • Azure DevOps Git

　

  • どちらを使うかは好みの問題もあります。判断ポイントとしては以下のような観点もあるかと思います。
    • すでに企業内・チーム内で導入が進んでいるほうを使う
    • 開発者が一人のみで、ADFの設定バックアップ目的でGitを使う場合はGitHubを使う
      • 私がGitHubのほうが慣れているのもありますが、ユーザ数が多いためMCP Server対応なども早く、生成AIによる恩恵（設計書の自動生成もしくは設計書自体を不要としチャットベース運用にする、自然言語による変更作業など）を受けやすい印象です。
    • 複数環境のADFインスタンスを使うのであれば、DevOps Gitを使う
      • CDとしてAzure DevOpsパイプラインを使うことになるため、CIとCDをMicrosoft製品に統一できる。
        • 両者ともEntraIDでユーザを一元管理できるため操作がしやすい。

Gitリポジトリは途中で変更することもできますが、CDを行う段階では手戻りが多くなるため、CIの検証中にどちらかに決定することをおすすめします。

Git構成のセットアップ時に既存のGitHubリポジトリから取り込むことも可能です。この場合、リポジトリ内のファイル構成はADFのフォーマットに沿ったものである必要があります。

手順

ADFの設定バックアップ

Git統合を行うADFインスタンスにて、まず念の為ARMテンプレートのバックアップを取得してください。
image.png

GitHubの場合

GitHubのサインアップ手順は省略します。

【GitHub側】プライベートリポジトリの作成

ADFで設定する前にまずGitHub側でプライベートリポジトリを作成してください。
このとき、readme.mdを作成するオプションを忘れずに指定してください。これにより初回コミットが行われ、mainブランチが作成されますので、ADF側でブランチを参照できるようになります。

image.png

以上で、Git統合にGitHubを使った場合のリポジトリのセットアップは終了です。

AzureDevOpsの場合

AzureDevOpsのサインアップ

こちらはサインアップから手順を記載します。

  • AzureDevOpsのサインアップ用URLにアクセスします。

組織の作成

  • 組織を作成します
    • 組織名は全世界でユニークな名前にする必要があります。会社名や部署名、チーム名など、あるいはその組み合わせなどでよいかと思います。
    • ホストする地域は、ADFを利用しているリージョンをあわせるでよいかと思います。
    • image.png

プロジェクトの作成

  • 組織内のプロジェクトを作成します。

    • プロジェクト名を入力します。
    • Visibilityは、多くのADF環境ではインターネットに公開しないと思いますので、[Private]でよいかと思います。
    • image.png

  • プロジェクトが作成できました。

    • image.png

リポジトリの作成

  • リポジトリを作成します。

    • リポジトリ機能である[Repos]を選択します。

    • すでにDevOpsプロジェクト名と同じリポジトリが作成されていますが、ADF専用の新規リポジトリを作成します。

      • image.png

    • リポジトリタイプとリポジトリ名を指定します。

      • image.png

    • リポジトリが作成されました。

      • image.png

以上で、Git統合にAzureDevOpsを使った場合のリポジトリのセットアップは終了です。

ADFにおけるGit構成

リポジトリをGitHubまたはAzureDevOpsで作成したのち、ADFで設定を行います。

  • ADF Studioにログインし、左メニューの「管理」「Git構成」「構成」をクリックします。
    image.png

  • リポジトリの種類からどちらかを選択します。
    image.png

GitHubの場合

  • リポジトリの所有者欄は、記載のとおりURLにも表示される部分を入力します。
    image.png

  • ブラウザがリダイレクトされGitHubの認証画面が出ますので、ADFからのアクセスを承認します。
    image.png

  • 承認するとADFで「リポジトリ名」からプルダウンでGitHub側のリポジトリ名を参照できるようになります。

    • image.png

  • リポジトリの構成
    image.png

    • リポジトリ名
      • 上述したようにプルダウンから作成済みのリポジトリを選択します。
    • コラボレーションブランチ
      • GitHubのリポジトリにパブリッシュできるブランチを指定します。
      • 通常は mainブランチを指定する形でよいと思います。
        • 運用後は、子ブランチを順次作成し、mainブランチにマージしてからパブリッシュするという流れで利用することになります。
    • 発行ブランチ
      • パブリッシュ後に自動的に作成されるARMテンプレートの保存先のブランチ名を指定します。
      • 通常は、デフォルトの「adf_publish」のままでよいかと思います。
      • この「ARMテンプレート」というのは「ADFのJSONリソース」別ものであるということは理解しておく必要があります。（後述）
    • ルートフォルダー
      • ADFのJSONリソースがインポートされるフォルダ名を指定します。
      • 1つのリポジトリを今回の環境のADF以外の用途でも使う場合は、フォルダを分けるのをおすすめします。
      • 多くのケースではADF専用リポジトリを作ることと思いますので、デフォルトの「/」のままでよいかと思います。
    • カスタムコメント
      • デフォルトのまま、チェックありでよいかと思います。
    • 既存のリソースのインポート
      • 「既存のリソースをリポジトリにインポートする」
        • 今回はmainブランチを新たに作成しているため、mainブランチは空となっています。その前提で記載します。
        • Git統合を行う前から、ADFにリソースを作成済みの場合は、チェックし、mainブランチを選択してください。
          • それにより、ADF本体(ライブモード)で作成済みのリソースが、mainブランチにコピーされますので、このあと使うmainブランチにて、継続して開発ができます。

  • 適用を押すと、問題がなければGit構成が完了します。この時点で、裏ではADFのJSONリソースがGitHub側またはAzureDevOpsのReposにコピーされていきます。

    • GitHubにおける設定完了状態
      • image.png

AzureDevOpsの場合

  • [Microsoft Entra ID]にてADFを利用しているテナントを選択します。

    • image.png

  • リポジトリの構成

    • [Azure DevOpsの組織名]先ほど作成した組織をプルダウンから選択します。

    • [プロジェクト名]先ほどAzure DevOpsで作成したプロジェクト名を選択します。
      image.png

    • 先ほど作成した新規のリポジトリを指定してください。

      • 既存のADFのJSONのデータが入っているリポジトリがある場合は、「既存リソースのインポート」をチェックしたのち、インポート元を指定できます。

    • コラボレーションブランチ

      • ADFのリポジトリにパブリッシュできるブランチを指定します。
      • 通常は mainブランチを指定する形でよいと思います。
        • 運用後は、子ブランチを順次作成し、mainブランチにマージしてからパブリッシュするという流れで利用することになります。

    • 発行ブランチ

      • パブリッシュ後に自動的に作成されるARMテンプレートの保存先のブランチ名を指定します。
      • 通常は、デフォルトの「adf_publish」のままでよいかと思います。
      • この「ARMテンプレート」というのは「ADFのJSONリソース」別ものであるということは理解しておく必要があります。（後述）

    • ルートフォルダー

      • ADFのJSONリソースがインポートされるフォルダ名を指定します。
      • 1つのリポジトリを今回の環境のADF以外の用途でも使う場合は、フォルダを分けるのをおすすめします。
      • 多くのケースではADF専用リポジトリを作ることと思いますので、デフォルトの「/」のままでよいかと思います。

    • カスタムコメント

      • デフォルトのまま、チェックありでよいかと思います。

    • 既存のリソースのインポート

      • 「既存のリソースをリポジトリにインポートする」
        • 今回はmainブランチを新たに作成しているため、mainブランチは空となっています。その前提で記載します。
        • Git統合を行う前から、ADFにリソースを作成済みの場合は、チェックし、mainブランチを選択してください。
          • それにより、ADF本体(ライブモード)で作成済みのリソースが、mainブランチにコピーされますので、このあと使うmainブランチにて、継続して開発ができます。

  • 適用を押すと、問題がなければGit構成が完了します。「既存のリソースをリポジトリにインポートする」にチェックした場合、この時点で、裏でADFのJSONリソースがGitHub側またはAzureDevOpsのReposにコピーされていきます。

    • AzureDevOpsにおける設定完了状態
      • image.png

以上でADFにおけるGit構成の初期設定は完了です。
続いて、Mainブランチを保護する設定を行います。

mainブランチ保護設定

GitHubにおけるmainブランチ保護設定

mainブランチへのpushを禁止する設定については以下記事を参照ください。
https://zenn.dev/jin1125/articles/a38c360e3319b7

AzureDevOpsにおけるmainブランチ保護設定

ブランチポリシーの設定

  • mainブランチのポリシーを設定します。
    • [Repos] -> [Branches]を選択します。
    • 最初はmainブランチしかありません。mainブランチの右にある３点リーダから[Branch policies]を選択します。
    • image.png
    • [Require a minimum number of reviewers]を Onに設定します。
      • これによりそのブランチが保護され、プルリクエストによる変更のみを受け付けるようになります。mainブランチでADF Studioで直接変更した内容を変更することができなくなり、子ブランチで開発するという安全な開発体制ができあがります。
    • [Minimum number of reviewers]は、チーム人数にあわせて設定します。
      • 私の環境の場合は私しか使わないため、1で設定します。
    • [Allow requestors to approve their own changes] は、私しかいないチームであるため、チェックをつけます。これでプルリクエストを出した本人がレビューしマージできます。
      • image.png

各機能のポイント説明

  • 「ARMテンプレート」「ADFのJSONリソース」の違いについて
    • リポジトリ構成の「発行プランチ」で指定した「adf_publish」という項目はARMテンプレートのブランチ名と前述しました。これについて軽く触れておきます。
      • 「ARMテンプレート」
        • ADFの設定がAzureResourceManager形式で保存されたもの。
        • JSON形式です。例として以下のようなファイル構成になっています。
          • image.png
          • 多くのADFリソースは「ARMTemplateForFactory.json」内にまとめて入っています。
      • 「ADFのJSONリソース」
        • ADFの設定そのものです。
        • JSON形式です。例として以下のようなファイル構成になっています。
          • image.png
        • 「ARMテンプレート」とはフォルダ・ファイル構造が大きく違っていることがわかります。「ADFのJSONのリソース」は「ARMテンプレート」とは異なり、各ADFの機能ごとにフォルダが分かれており、視認性が高いものになっています。

本記事は以上です。
次回以降はAzureDevOpsをベースにCI/CDの実装環境を整えていきます。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?