Azure DevOpsを活用したマルチチーム開発: ソース管理とセキュアプラクティス

2023/10/07に開催されたTFSUGのAzure DevOpsオンライン Vol.9 ～ エンタープライズ向けGit運用でお話させて頂いたときの資料です。

当日お話しした内容はこんな感じです。

1. forking flowを構築して複数の開発チームでソースコードを運用していく
- forking flowの構築
2. チーム開発をしていく上でのセキュリティを担保したブランチ保護戦略について
- 上流、下流のReposを守るためのブランチ戦略
- 上流と下流の同期
3. PRトリガーの自動化でゆるくチームを縛って予想外の変更からソースコードを守る
4. セキュリティを担保したpipelineの構築&運用プラクティス

Transcript

1. Azure DevOpsオンライン Vol.9 ～ エンタープライズ向けGit運用
2. • Agile Specialist@Avanade Jappan • DevOps&Agile Coaching • C#, Azure, .Net, Power Platform • Azure DevOpsを使ったスクラムの実践やチーム開発環境の構築・運用をテーマに登壇した りしてます 森　友梨映（Yurie Mori）
3. Azure DevOpsを活用したマルチチーム開発: ソース管理とセキュアプラクティス
4. このパートのアジェンダ 1. forking flowを構築して複数の開発チームでソースコードを運用していく - forking flowの構築 2. チーム開発をしていく上でのセキュリティを担保したブランチ保護戦略について - 上流、下流のReposを守るためのブランチ戦略 - 上流と下流の同期 3. PRトリガーの自動化でゆるくチームを縛って予想外の変更からソースコードを守る 4. セキュリティを担保したpipelineの構築&運用プラクティス
5. 1. forking flowを構築して複数の開発チームで ソースコードを運用していく
6. 複数のPJでソースコードを運用したい • Alphaの最新のソースが見れるようにしたい • Bravoで開発中のソースはAlphaから取得し たソースとぐちゃぐちゃになってほしくない • 必要に応じてAlphaから取得したソースを Bravoの開発中のソースにmergeしたい • Bravoからの意図しない変更によってAlpha のRepositoryは一切汚されてはならない。 今回の要件 同一のOrganizationの配下に2つのPJが存在している
7. Forkをつかう Forkってなに？ repositoryのコピーを作る操作のことをいいます（ & Fork で作ったReposのこともForkといいます）。 単純なReposのimportと違って、オリジナルのReposか らのpull、オリジナルへのpush&PR作成もできて、 repositoryを超えたコラボレーションができます。 ※👆のフォークみたいにソースが分岐していくことをさして forkというらしい
8. Forking workflowをざっくり考えてみる 上流 下流 Step1:Forkの作成 Alphaの最新のソースがBravoで見れるように、Bravo にAlphaのReposをforkする これで下流から変な変更がきても PRをRejectすれば変な変 更から上流のmainブランチを守れる Alphaの最新のソースが見れるよう にしたい の要件はこれでクリア！ Step2: 上流が更新されたら PowerAutomateで通知 Step3: 上流と下流のソースの同期 通知が来たらBravoでAlphaの最新の変更を取得す る。
9. 実際にForkつくってみます
10. 2. チーム開発をしていく上でのセキュリティを担 保したブランチ保護戦略について
11. 上流Reposを守るためのブランチポリシーの設定 まずブランチをLockしてPR作成 しないとmergeできないようにす る レビューされないとmergeでき ないようにする これで下流から変な変更がき てもPRをRejectすれば変な 変更から上流のmainブランチ を守れる！ Bravoからの変更によって AlphaのRepositoryは一切汚 されてはならない もこれでクリア！
12. 下流Reposのブランチ戦略 これをalphaからソースを受取る 専用ブランチにする conflict怖い方はこちらの防御力高めのブランチ戦略で alpha-baseとmainの間に統合専用のブラ ンチを作る メリット： 統合のコストが少ない デメリット： 好ましくない変更に対する防御力が低い メリット： 好ましくない変更に対する防御力が高い デメリット： 統合がめんどくさい Plan A Plan B mainは上流と同じでlock&レ ビューされないとmergeできな いように
13. Bravoで開発中のソースはAlpha から取得したソースとぐちゃぐちゃ になってほしくない →これもOK 必要に応じてAlphaから取得したソース をBravoの開発中のソースにmergeし たい →これもクリア！ 上流からの受取り用ブランチ alpha-baseを置くことでmainと 分離できる 必要に応じてmerge
14. 上流に更新が入ったらPowerAutomateで通知(1/2) Power Automate copilotを使うとこんな 感じで自然言語からフローを提案してく れる
15. 上流に更新が入ったらPowerAutomateで通知(2/2) 上流のProject_Alphaのmainブランチに 変更が入ったら通知してもらうようにする これで同期漏れを回避
16. 上流と下流を同期する PR作成画面でReposとbranchを指 定して、変更があるとPR作成できる ようになる
17. 実際に見てみましょう
18. Pipelineで上流と下流のソース同期を自動化 見せられないよ
19. Pipelineの詳しいレシピはこちらの記事をcheck!
20. Q&A
21. • Application Architect@Avanade Jappan • TypeScript, Python, Go, Dart, C#, Azure, GCP • なんでもやる事を心掛けて、エンジニアリングをしてます。 Azure DevOpsは初心者 山本　学（Gaku Yamamoto）
22. 3. PR Triggerの自動化でゆるくチームを縛って 予想外の変更からソースコードを守る
23. 問題とモチベーション 問題： ・開発ルールの増加に応じて、個々の開発者のローカル開発環境で実行する事が　増 加していく。 モチベーション： ・開発者には、ソースコードを書くことに集中してほしい。 ・一貫性・包括性・即時性の観点で、レビュー作業の最低レベルを上げたい。 ・主要ブランチ（main/develop）に変更が入る前に上記を検知したい。 例：テスト実行とレポート生成、コードクオリティチェック、コードカバレッジチェックなど
24. 自動化のアプローチ1 使用機能： ・pull request trigger Azure Pipelineでは、デフォルトでリポジトリ内のすべてのブランチに対する コードのプッシュがパイプラインのトリガーとなってしまうので、 excludeで*を 指定する事で、全てのブランチを除外する。 developブランチへのPull Requestでトリガーする様に設定。 Pull Request作成以降は、当該ブランチに Push毎に起動。 ↑以降はstagesで自動化対象のジョブを記述する。
25. 自動化のアプローチ2 設定： ・Build Validation Pull Request先のBranch のBranch policyのBuild Validationをで作成したpull request trigger用の pipelineを選択する。
26. まとめ ・Azure DevOps上でpull request triggerを動作させるための設定を学んだ。 　・ymlファイルでpull request用のパイプラインを作成 　・Build Validationで作成したパイプラインを選択する ・trigger句のデフォルトの仕様を知らずに、苦しんだ。 ・各stageで実行する内容を精査しないと、強い縛りになるので、シンプルな縛りを心掛 けた方が開発効率が下がらないと実感。
27. 4. セキュリティを担保したpipelineの構築&運用 プラクティス
28. 問題とモチベーション 問題： ・pipeline内で作成されたDocker ImageをPushする先のAzure Container Registryに PEとNSGによって特定のIPからしか接続できない状態になった。 ・Azure DevOps Servicesエージェントは実行毎に異なるIPアドレスを持つので、都度IP 制限によりDocker ImageのPushができない。 Azure pipeline Azure Container Registry モチベーション： ・Self Hosted agentを使用して、安定したIPアドレスを保持してpipelineを実行したい。
29. なんでSelf Hosted Agentにしたのか？ ・Azure DevOps ServicesのパブリックIPアドレス範囲をIP制限に追加する事で、実現 もできるが、変更の可能性が残る。
30. Self Hosted Agentによる環境イメージ 1. ・Azure DevOpsにパイプラインの定義。 2. ・VM上で登録されたAgentがジョブを実行。 3. ・AzureDevOpsには、VM上で実行された結果が返却される。 Azure DevOps Azure Container Registry Virtual Machine 同一ネットワーク job実行
31. Agentの作成方法 ※pipelineの作成とVM環境作成は既にされている事を想定して省略します。🙇 1. Personal Access Tokenの取得 2. PoolとAgentの作成とダウンロード
32. 1.Personal Access Tokenの取得 Show all scopesを押下して、Agent Poolsにチェックを入れることを忘れずに。 最初見当たらずに焦りました w
33. 2.1PoolとAgentの作成とダウンロード 「Add pool」を押下して、Pool typeは「Self-hosted」を選択して、任意の名前で作成します。
34. 2.2PoolとAgentの作成とダウンロード 作成したPoolを選択し、Agentを作成します。 あとは、VM環境上で画像右の内容の通りに、 OS毎にダウンロードができるのでダウンロードをしてください。シェ ルを実行してウィザードに従って必要な設定を入力すれば OKです。
35. まとめ ・セキュアにというよりも、IP制限によってネットワーク制限がかけられた環境下でもパイ プラインを動作させる為の方法がわかった。 ・Azure DevOpsとAzure間できる事多い。（小並感）
36. Q&A