kkamegawa's weblog

Visual Studio,TFS,ALM,VSTS,DevOps関係のことについていろいろと書いていきます。Google Analyticsで解析を行っています

GitHubのProjectを使って、Azure DevOpsの複数のプロジェクトを集約して管理する

はじめに

前のエントリー公開後、このようなお便りをいただきました。ちょうど一回やってみたかったことなので、書いておきます。

簡単な解決方法

簡単な方法としてはクエリー作るときにQuery Across Projectsにチェックを入れることです。

docs.microsoft.com

f:id:kkamegawa:20201004172151p:plain

チェックしない場合。

f:id:kkamegawa:20201004172147p:plain

チェックした場合。商品一覧の表示というfeatureが追加されていますね。これは別のプロジェクトのWork Itemです。もっとも簡単なのはこのパターンでしょう。

Azure DevOpsはOrganizationをまたがるのはユーザー管理の観点から今のところサポートされていません。

でもこうじゃなくて、もうちょっと全体を俯瞰してみたい場合、GitHubを使ってやってみようかなという方法を紹介します。

docs.microsoft.com

GitHub Projectを使って管理する

GitHub Projectという機能があります。issueをまとめて管理するカンバンですね。でも今回はAzureの機能を使うので、github-actions-issue-to-work-itemというActionを使ってみましょう。

github.com

Azure Boardsアプリをインストールする

docs.microsoft.com

事前にAzure Boardsアプリをインストールしておいてください。

GitHub接続を作る

f:id:kkamegawa:20201004172059p:plain

Service ConnectionからGitHubへの接続を作っておきます(たぶん要らないとは思いますが)。

f:id:kkamegawa:20201004172104p:plain

GitHub Projectを作る

f:id:kkamegawa:20201004172108p:plain

告知用のレポジトリからProjectを作ります。

f:id:kkamegawa:20201004172128p:plain

レポジトリからActionsを作ります。接続するプロジェクトを選びます。YAMLのサンプルはレポジトリにあるのでそのままぱっくんちょすればいいです。

サンプルはAgileプロセス前提で作っているので、ScrumやBasicを使う場合、ado_witや、ado_active_statusを該当プロセスの値に変えることを忘れないでください。

API Keyを作る

docs.github.com

GitHubとAzure DevOps側にPATを作っておく必要があります。

f:id:kkamegawa:20201004172112p:plain

Azure DevOpsではrepoのRead & Write(余計なManageまでついていますが)だけ必要です。

f:id:kkamegawa:20201004172120p:plain

GitHubではrepoのフルが必要です。

f:id:kkamegawa:20201004172124p:plain

f:id:kkamegawa:20201004172116p:plain

作ったレポジトリにADO_PERSONAL_ACCESS_TOKENGH_PERSONAL_ACCESS_TOKENの二つのシークレットを作って、PATを貼り付けます。

issueに追加

f:id:kkamegawa:20201004172143p:plain

GitHub側でIssueを作ると、登録したActionsが動いて、自動的にAzure Boardsに反映されます。

f:id:kkamegawa:20201004172138p:plain

Azure Boardsに作られた例。これでAssignやAreaなどを直せばいいでしょう。

f:id:kkamegawa:20201004172133p:plain

作られたissueはProjectに登録されるので、わかりやすいです。Issueのステートと連動するので、GitHub側でCloseすれば自動的に変更されます。

まとめ

GitHub Projectsでは複数のレポジトリのissueの登録ができます。仕事などでGitHubのorganizationを運用している場合、この方法でまとめていけばいいんじゃないかなと思います。

ちょっとどっちが正になるかわかりづらいかもしれないですが、大きなプロジェクト全体で見るようなレベルのものに関してはGitHubで作っておく、そうじゃないものはAzure Boardsで管理するみたいなこともできるので、場合によっては便利に使えるかもしれません。