Azure ReposのGitもGitHub同様にforkできるのですが、あまり使われてないんじゃないかなぁ、という個人的な印象があります。チームプロジェクトと、Gitのレポジトリわかりづらいかもしれません。そこで用途別のforkについてこうしたらいいんじゃないかなケースでまとめてみます。
請負パートナーと同じorganizationで作業する
日本の法律的に請負で契約している会社のメンバーに対しては作業指示に関して制限があります。そんなときに使えるのがチームプロジェクトを超えたforkです。メリット。
- Environmentやtask, Libraryなどの名前はプロジェクトローカルなので、同じ名前が使える
- サブスクリプション単位で費用分割可能
- Service Connectionもそれぞれ分割可能
- 権限もそれぞれのチームで設定可能で、お互いのチームでメンバーの検索はできない
デメリット
- 別のチームを管理する人が必要になるので面倒
- マネージメントする人が割と大変
正直法律上の制限のため仕方ない場合を除いてチームプロジェクトを超えるforkはお勧めできません。
同一組織内の開発者で作業する
チームプロジェクトに別のGitレポジトリーを作ってforkします。多分これがだいたいいいんじゃないかなぁとは思います。メリットはこんなところでしょうか。
- GitHubなどとだいたい同じのforkの感じで使える
- しかし、GitHubとは違ってタスクは同じAzure Boardsで管理できる
- 作業項目がごっちゃになってわかりづらくなるので、area pathとチーム構成で権限を設定するのがおすすめです
- パイプラインも別管理できる（マージするときに入れないようにしよう）
デメリット
- Environment, Task, Libraryを共有することになるのでネーミングルールとパイプライン定義重要
- パイプラインがごっちゃになるので、フォルダー分け、権限管理もやりましょう。
- Service Connection使ってサブスクリプションを別管理するときはService Connection単位で使えるパイプラインを明示的に設定するのがおすすめ
- 重要なリソースであればapproverも設定して、connectionに対して承認設定しましょう。
割と万人向けではあるかもしれないけど、管理で混乱しないようにしましょう。
チーム開発向け
モノレポでブランチのみを使った開発ですね。個人もしくは数人、Azure Web Appみたいにスロットを元から持っているようなPaaSへのデプロイであればこの携帯で十分じゃないかなと思います。シンプルでわかりやすい。
モノレポの場合、10GB までという制限があります。ソースコードだけであればここまで行くことは多くないと思いますが、ドキュメント、画像、動画などを入れてしまうと割といってしまうので気をつけてください。
終わりに
パッと思いつく感じのforkでまとめてみましたが「こんな感じでやってる」とか「こういう場合はどうすれば」とかあればコメント, Slack, Twitterなどで教えてください。
