はじめて Azure DevOps を使うチームに、Azure DevOps でどういうことができるのか？を説明するときには私はいつも、こんな感じの表を使って説明します。
Azure DevOps は、他のさまざまなサービスを組み合わせて実現する部分を、代わりにAzure DevOps だけで実現できるようにカバーしています。そのため、似ている他のサービスをあげて説明するとわかりやすいようです。例えば、もともと「CI/CD に使おう」と思っていたケド、「作業管理も手動テストの管理もできるなら、それも一緒に扱えるようになりたい」という話になったりします。
また、私は、今はまだ GitHub を Azure DevOps の代わりに使うことが出来ないと思っていますが、それはこの表にあるとおり、チーム開発するときに特に重要な作業管理の部分などを、まだ今の GitHub は扱うことが出来ていないからです。この辺りは近々の GitHub のアップデートで変わっていくかもしれません。そうなってきたら、また表をアップデートして、GitHub と Azure DevOps の比較もしていきたいですね。
目次
Overview : ダッシュボード・見える化・共有
Azure DevOps のメニュー順の一番上は、いわゆるダッシュボードです。プロジェクトの説明（README.md）や他の機能の今の利用状況のチャートなどを、プロジェクトのメンバーに見えるように共有する場所です。
他の機能を理解してからでないとイメージができない部分もあるので、たいていさらっと流して説明します。
Boards : 作業管理・要件と課題管理・リリース計画
２番目の Boards は、Scurm（アジャイル）のプロジェクトで使う場合はそのままイメージがしやすい部分です。Scrum のバックログと、それをスプリントで扱うためのカンバンボード。そして、複数のスプリント進んだときに、いったいどのPBIがいつ頃完成させられてリリースできる見込みなのか？を予測して計画するためのリリース計画の機能があります。
見積もりをするためのプランニングポーカーやレトロスペクティブの画面も（デフォルトではありませんが、拡張機能をインストールすると）使えます。
もしプロジェクトが Scrum ではない場合でも、Boards を使うことが出来ますが、その場合は１つだけ注意が必要です。Azure DevOps は Sprint （期間） で Task を扱うので、Task ごとに期限を日付で入れるような管理にはちょっと向いていないです（それに適したビューがありません）。代わりに１週間ごとなど、期間の中で Task が終わればよい、という感じで管理できれば、Azure DevOps でも WBS（Work Breakdown Structure）と Task を扱うことが出来ます。
似ているのは Redmine や Jira です。
Repos : ソースコード管理
Azure DevOps に Git があります。それが Repos です。古いソースコードのバージョン管理の仕組みも残っていますが、現代では使わなくて良いと思います。
GitHub かそれ以外の Git を使ったことがある人には、Repos に「Gitのリポジトリがある」と伝えればOKです。
Git を詳しく知らない人向けに説明するときには、ソースコードを保存するときに履歴が残せることと、Boards と連携すれば「どの要件・作業に関する変更か？」を履歴に関連付けてソースコードを保存出来て、後からトラッキング仕組みであることを説明します。
Pipeline : CI/CD・自動テスト
継続的インテグレーション・継続的デリバリーを担う部分が Pipeline です。Repos に保存されたソースコードをビルドしたり、ステージ（環境）に配置したりします。その間に自動で静的解析や単体テストを実行したり、責任者（人）による承認を必要にしたり、といった感じで、ステージでのステップと、ステージ間のフローを構成できます。
自動ビルドや開発環境への配置や、検証環境への配置までしか活用されていないことも多いのですが、本番環境へのリリースまでを構成して使うのがよいというのを、早めに偉い人に説明しておきます。そうしないと、本番環境へ Azure DevOps を繋げないまま話が進んでしまいます。逆に早めに伝えて調整しておくことで、本番環境にAzure DevOpsを接続する前提で進められます。
Azure DevOps の Pipeline に標準ではサポートされていないような配置も、PowerShell がPipeline で使えることで、また専用のビルド・配置用のマシンを構成することもできるので、何とか連携できることが多いです。
GitHub Actions や、Jenkins、docker、SonarQube、Selenium のどれかを扱ったことがある人には、それを扱う部分と言えば伝わると思います。そうでない人には、なぜ必要なのか？から説明しなければならなくて最も大変な部分ですし、CI/CDを説明しなければならないケースなら Pipeline には手を出さないのがいい気がします。
Test Plans : 手動テスト
手動で実行するテストの管理はこの Test Plans を使います。テストケースとテスト結果の管理ができます。多くの場合、Excel ファイルでテストケースを書いて、そこにそのままテスト結果を入れて、キャプチャ画像をファイルでとっているかExcelファイルにそのまま貼り付けているように思います。しかし、これらの操作感そのままで、Web で扱えるようになります。見た目にわかりやすく、とても好評です。一度デモをして見せれば大抵OKです。
ただ、ひとつだけ注意点があります。テスト計画を作る人（Azure DevOpsのユーザー）は、ひとつ上のライセンスが必要です。５人まで無料の Basic プランではテスト計画は作れません。テストの実行と結果の記録は、Basic プランで出来ます。テスト計画を作る人の人数だけ注意してください。
Boards で要件を管理できている場合、要件をどのテストケースでテストできたか？という管理ができるので、品質を保つのに役立ちます。逆に Test Plans だけでテストケースを扱おうとするケースでは、テストがなぜ必要か？がわかっていない場合があって、テストケースをうまく作れないというところからケアしないといけない場合があります。
Artifacts : アーティファクト管理
Repos でソースコードを共有するのではなくて、完成したライブラリを NuGet のようにちゃんとバージョン番号を付けて共有して、それを参照してもらって使えるようにするのが Artifacts です。もう作りかけのライブラリを使われて、「それは変更中だから」と説明して回る必要はありません。
共有のライブラリやフレームワークを作っているような人であれば伝わるので、ピンとこないケースでは必要ないはずです。
コメント
