はじめに
この記事は Azure DevOps - Qiita Advent Calendar 2024 - Qiita の 23 日目の記事です。
Azure DevOps に関わっているエンジニアが最近よく聞かれる質問、第 1 位は...
GitHub (Enterprise Cloud) と Azure DevOps (Services) ってどっちが良いの？
です。
この質問に対するシンプルな答えは「悩んでいるなら、GitHub を選びなさい👼」となりますが、話はそんなに単純ではありません。
"GitHub を選ぶべき理由" は巷に大量の情報があるので、本記事では「あえて "今から" Azure DevOps を選びたいとき」ってどんなケースか、という話を書きます。
なお、「Azure 製品だと社内申請が通りやすいんだけど、GitHub は実績が無い/少ないから大変で..」という話もよく聞くポイントですが、そういう "社内事情" は今回の話から除外します。
移行元が Team Foundation Server / Azure DevOps Server だから選ぶ
Azure DevOps にはクラウド版とオンプレミス版があり、オンプレミス版は "Azure DevOps Server" という名称です。またその前身となる製品は Team Foundation Server (TFS) でした (2019 から改称)。
これらツールを使っていて、同じ使い勝手のクラウド ツールに移行したい場合は、今も Azure DevOps Services が最良の選択肢の 1 つです。
Microsoft Entra ID で管理したいから選ぶ
もしあなたが、「Microsoft Entra ID でアカウント管理をしています」、「製品開発は Microsoft Azure を使っています」と言った場合、DevOps ツールのアカウント管理も Microsoft Entra ID を使えたら便利ですよね。
たとえば、「出荷物を配置する社内ファイル サーバーへのアクセス権限と、そのファイル サーバーに配置するパイプラインの権限は、同じ部署のメンバー (グループ) に与えたい」という場合、Microsoft Entra ID なら一元管理できます。
GitHub Enterprise でも EMU (Enterprise Managed Users) やチーム同期を設定すれば、類似したことが可能ですが、正直 Azure DevOps のほうが簡単です。
課題管理ツール (Azure Boards) で選ぶ
Azure DevOps の中で "キモ" となる機能は何かと聞かれたら、それは "Azure Boards" です。
Azure Boards は Azure DevOps 内の各サービス (Azure Repos, Azure Boards, Azure Pipelines, Azure Artifacts, Azure Test Plans) を横断的に統合し、エンドツーエンド (最初から最後まで) の追跡を可能にします。
たとえばバグがあった時、そのバグはいつ報告され、誰が直し、いつ出荷されたのかという情報は Azure Boards 上で管理されますが、Azure DevOps のすべての機能を使っている場合は、バグ報告時のテスト結果の詳細 (Azure Test Plans)、具体的なソースコードの修正内容 (Azure Repos)、影響のある要件 (Azure Boards)、修正後の出荷物 (Azure Pipelines/Azure Artifacts) への参照リンクも、自動的に関連付けされます。
他社製品でも同様のことは組み合わせ・構成することで可能ですが、これが標準機能として提供されているのは大きなポイントです。(ちなみに、Azure Boards は GitHub とも連携できます)
従量課金要素で選ぶ
"あまり知られていない" と個人的に思っているのですが、Azure DevOps というサービスは従量課金要素の少ない大判ぶるまいなサービスです。
特に影響が大きい 2 つのポイントについて説明します。
- リポジトリ (Azure Repos)
- パイプライン (Azure Pipelines)
リポジトリ (Azure Repos)
Azure Repos は 2 つのバージョン管理方式をサポートしていますが、「まさか今から Team Foundation バージョン管理 (TFVC) を使おうとする人はいない」と思うので、Git リポジトリを前提とします。
2012 年以前からソフトウェア開発をしていて、以前は Subversion などの集中バージョン管理を使っていた人/チームは、次の情報もリポジトリの中に入れるものと思いがちです。(保存しているとヤバい順)
- 製品をビルドするために必要なツール類一式
- お客様に出荷した最終成果物一式
- 依存関係のあるライブラリ一式
- 外部設計書/詳細仕様書などの開発ドキュメント一式
これらの Git リポジトリに保存すると、当然ながら次の問題が発生し、開発全体の生産性を大幅に下げます。
- リポジトリのクローンに時間がかかる (しかも時間の経過と共に、時間は長くなる!)
- CI/CD などの自動化の処理時間が長くなる (しかも、これがコストに繋がる...!)
何より、クラウド ストレージ自体を逼迫するので、多くの DevOps サービス (特にクラウド) では一定サイズ以上のファイル サイズの PUSH を拒否します。(GitHub の場合、1 ファイル 100 MiB まで)
このような場合に出てくるのが Git Large File Storage (LFS) です。
Git LFS については説明しませんが、このストレージは多くの場合、従量課金要素の１つです。
たとえば GitHub Enterprise Cloud の場合、250 GiB までの無料枠があり、それを超過すると 1 GiB あたり $0.07 料金が発生します (月額)。
特に厄介なのは、このストレージ容量は基本的に "増えることはあっても減ることはない" ということです。
対して、Azure DevOps (Azure Repos) はどうかというと、ユーザー ライセンスの中に含まれ、従量課金要素ではありません。(常識の範囲を逸脱していると、開発チームから本気で怒られます)
パイプライン (Azure Pipelines)
Azure Pipelines に限らず、多くの CI/CD サービスはそのパイプライン (GitHub Actions の場合はワークフロー) を実行する環境 (Azure Pipelines の場合は、エージェント。GitHub Actions の場合はランナー。) は従量課金要素の 1 つです。
大抵のサービスでは、1 分あたりの従量課金なのですが、Azure Pipelines の場合は並行実行台数で課金、という少し特殊な料金体系になっています。
仮に Azure Pipelines の並列実行台数を 1 台購入した場合、1 台のマシンを OS の種類に関係なく 無制限 で使えます。(ただし、実行あたりの最大時間に制限があります)
まとめ
繰り返しですが、今から DevOps ツールを検討するなら、まずは GitHub を検討してください。
その上で、上記のポイントに該当するなら Azure DevOps も検討してみてください。
なお、最近 Microsoft Ignite 2024 で GitHub Enterprise に Azure DevOps Services (Basic) のライセンスが付与されることが発表になったので、プロジェクトの状況などに応じて両方使うというのもライセンス費用 (コスト) 面で敷居が下がったと思います。
ぜひご自身に合った選択肢を適切に選んでください。
