こんにちは。コンテナソリューショングループの髙井です。
今日はAzure DevOpsの記事です。
Azure DevOpsは、何も知らなくてもサッと使い始められるようになっています。
一方で、同じ環境で使う人が増えてくると、イイ感じに分けて使いたくなったりして、そんなときにどうすれば〈イイ感じ〉にできるのか悩んだりすることもあるかと思います。
今回は、よくある分けたいニーズとしてボードを複数使いたいケースを取り上げます。
結論
いきなりですが、タイトルについての結論です。
以降は、各語句についての説明や考え方を記載します。
組織、プロジェクト、チーム
大きいものから順に、組織、プロジェクト、チームです。
組織とは
ある〈組織〉に対して、必ず1つのAAD（Azure Active Directory）テナントが親になっています。
複数のテナントを親として持つことはできません。
したがって、複数のテナントにまたがるユーザーを同じ〈組織〉に所属させたい場合、先に親となるAADテナント側でゲストユーザーとして招待しておく必要があります。
プロジェクトとは
1つの〈プロジェクト〉には、おなじみのBoardsやRepos、Pipelinesなどの各種サービスが含まれます。
Azure DevOpsを開始する場合、まず組織を作成し、その中に〈プロジェクト〉を1つ作成すれば、さしあたっては利用を始めることができます。
チームとは
ここで生じる問題は、複数の企画1を扱う際に、やり方が大きく2通りに分かれることです。
- ひとつのプロジェクトの中に複数のチームを作る（single projectパターン）
- ひとつのチームからなるプロジェクトを複数作る（many projectsパターン）
実際には、複数のチームからなるプロジェクトを複数作ったり、組織を複数作ったりもできますが、論点を明確にするため今回は含めません。
one project と many projects
Azure DevOpsを手探りで使っている場合、おそらく自然と many projects のパターンになっていることが多いと思います。
なぜなら、1つのプロジェクト内に複数のチームを作るにはUI上で深い項目に到達する必要があるからです。
とはいえ本来ならば one project と many projects のメリット・デメリットを検討したうえでパターンを決定したいところです。
実は、公式ドキュメントにも「組織の構造を計画する」というページがあります。
多くの内容が記載されていますが、キモはOverviewやRepos、Pipelinesなどを共有したいかどうかです。
many projects
同じ会社内で、まったく違う部署のまったく違う企画がある場合はプロジェクトを分けるほうがよいでしょう。
お互いの情報にアクセスする必要がほとんどないことが予想されるからです。
one project
もちろんチームごとに権限を制限することもできますが、明示的な設定が必要になります。プロジェクトを分けるのに比べて情報の分離性は低いです。
また、最初に結論で述べた通り、チームを複数作成するとチームごとに独自のボードが作成されます。
小規模な部署で、一部のメンバーが重複しながら複数の企画にアサインされている場合など、アセットの切り分けが難しくなってきます。
こうしたケースでは、単一のプロジェクトの中に複数のチームを作ったほうが管理コストは小さくなると予想されます。
チケットとスプリント期間はボードごとに設定できる
おそらくボードを分けたい理由でいちばん最初にくるのが〈スプリント期間を別々に設定したい〉だと思います。
同じアセットを使用しているものの、担当領域の違いで区切りの違うスプリントが並行して走っているシーンなど、ぜひご活用ください。
おわりに
手探りでAzure DevOpsを利用し始めてしばらく経ったころに気になるあたりを想定して書きました。
利用が拡大してくると、管理面でのケアが必要になってきますね。実際には、今回の内容に加え、権限まわりも理解していく必要があります。
権限まわりは組織構造よりさらに複雑というか階層が多いので、近いうちにザックリまとめた記事を書くつもりでいます。
-
Azure DevOpsにおける〈プロジェクト〉と表記がかぶるため、一般的なプロジェクトと同じ概念として〈企画〉と表現しています。↩
