Tweet
Tweet

Slide 1

Slide 1 text

Azure DevOpsオンライン Vol.9 ～ エンタープライズ向けGit運用

Slide 2

Slide 2 text

● Agile Specialist@Avanade Jappan ● DevOps&Agile Coaching ● C#, Azure, .Net, Power Platform ● Azure DevOpsを使ったスクラムの実践やチーム開発環境の構築・運用をテーマに登壇した りしてます 森　友梨映（Yurie Mori）

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

1. forking flowを構築して複数の開発チームで ソースコードを運用していく

Slide 6

Slide 6 text

複数のPJでソースコードを運用したい ● Alphaの最新のソースが見れるようにしたい ● Bravoで開発中のソースはAlphaから取得し たソースとぐちゃぐちゃになってほしくない ● 必要に応じてAlphaから取得したソースを Bravoの開発中のソースにmergeしたい ● Bravoからの意図しない変更によってAlpha のRepositoryは一切汚されてはならない。 今回の要件 同一のOrganizationの配下に2つのPJが存在している

Slide 7

Slide 7 text

Forkをつかう Forkってなに？ repositoryのコピーを作る操作のことをいいます（ & Fork で作ったReposのこともForkといいます）。 単純なReposのimportと違って、オリジナルのReposか らのpull、オリジナルへのpush&PR作成もできて、 repositoryを超えたコラボレーションができます。 ※👆のフォークみたいにソースが分岐していくことをさして forkというらしい

Slide 8

Slide 8 text

Forking workflowをざっくり考えてみる 上流 下流 Step1:Forkの作成 Alphaの最新のソースがBravoで見れるように、Bravo にAlphaのReposをforkする これで下流から変な変更がきても PRをRejectすれば変な変 更から上流のmainブランチを守れる Alphaの最新のソースが見れるよう にしたい の要件はこれでクリア！ Step2: 上流が更新されたら PowerAutomateで通知 Step3: 上流と下流のソースの同期 通知が来たらBravoでAlphaの最新の変更を取得す る。

Slide 9

Slide 9 text

実際にForkつくってみます

Slide 10

Slide 10 text

2. チーム開発をしていく上でのセキュリティを担 保したブランチ保護戦略について

Slide 11

Slide 11 text

上流Reposを守るためのブランチポリシーの設定 まずブランチをLockしてPR作成 しないとmergeできないようにす る レビューされないとmergeでき ないようにする これで下流から変な変更がき てもPRをRejectすれば変な 変更から上流のmainブランチ を守れる！ Bravoからの変更によって AlphaのRepositoryは一切汚 されてはならない もこれでクリア！

Slide 12

Slide 12 text

下流Reposのブランチ戦略 これをalphaからソースを受取る 専用ブランチにする conflict怖い方はこちらの防御力高めのブランチ戦略で alpha-baseとmainの間に統合専用のブラ ンチを作る メリット： 統合のコストが少ない デメリット： 好ましくない変更に対する防御力が低い メリット： 好ましくない変更に対する防御力が高い デメリット： 統合がめんどくさい Plan A Plan B mainは上流と同じでlock&レ ビューされないとmergeできな いように

Slide 13

Slide 13 text

Bravoで開発中のソースはAlpha から取得したソースとぐちゃぐちゃ になってほしくない →これもOK 必要に応じてAlphaから取得したソース をBravoの開発中のソースにmergeし たい →これもクリア！ 上流からの受取り用ブランチ alpha-baseを置くことでmainと 分離できる 必要に応じてmerge

Slide 14

Slide 14 text

上流に更新が入ったらPowerAutomateで通知(1/2) Power Automate copilotを使うとこんな 感じで自然言語からフローを提案してく れる

Slide 15

Slide 15 text

上流に更新が入ったらPowerAutomateで通知(2/2) 上流のProject_Alphaのmainブランチに 変更が入ったら通知してもらうようにする これで同期漏れを回避

Slide 16

Slide 16 text

上流と下流を同期する PR作成画面でReposとbranchを指 定して、変更があるとPR作成できる ようになる

Slide 17

Slide 17 text

実際に見てみましょう

Slide 18

Slide 18 text

Pipelineで上流と下流のソース同期を自動化 見せられないよ

Slide 19

Slide 19 text

Pipelineの詳しいレシピはこちらの記事をcheck!

Slide 20

Slide 20 text

Q&A

Slide 21

Slide 21 text

● Application Architect@Avanade Jappan ● TypeScript, Python, Go, Dart, C#, Azure, GCP ● なんでもやる事を心掛けて、エンジニアリングをしてます。 Azure DevOpsは初心者 山本　学（Gaku Yamamoto）

Slide 22

Slide 22 text

3. PR Triggerの自動化でゆるくチームを縛って 予想外の変更からソースコードを守る

Slide 23

Slide 23 text

問題とモチベーション 問題： ・開発ルールの増加に応じて、個々の開発者のローカル開発環境で実行する事が　増 加していく。 モチベーション： ・開発者には、ソースコードを書くことに集中してほしい。 ・一貫性・包括性・即時性の観点で、レビュー作業の最低レベルを上げたい。 ・主要ブランチ（main/develop）に変更が入る前に上記を検知したい。 例：テスト実行とレポート生成、コードクオリティチェック、コードカバレッジチェックなど

Slide 24

Slide 24 text

自動化のアプローチ1 使用機能： ・pull request trigger Azure Pipelineでは、デフォルトでリポジトリ内のすべてのブランチに対する コードのプッシュがパイプラインのトリガーとなってしまうので、 excludeで*を 指定する事で、全てのブランチを除外する。 developブランチへのPull Requestでトリガーする様に設定。 Pull Request作成以降は、当該ブランチに Push毎に起動。 ↑以降はstagesで自動化対象のジョブを記述する。

Slide 25

Slide 25 text

自動化のアプローチ2 設定： ・Build Validation Pull Request先のBranch のBranch policyのBuild Validationをで作成したpull request trigger用の pipelineを選択する。

Slide 26

Slide 26 text

まとめ ・Azure DevOps上でpull request triggerを動作させるための設定を学んだ。 　・ymlファイルでpull request用のパイプラインを作成 　・Build Validationで作成したパイプラインを選択する ・trigger句のデフォルトの仕様を知らずに、苦しんだ。 ・各stageで実行する内容を精査しないと、強い縛りになるので、シンプルな縛りを心掛 けた方が開発効率が下がらないと実感。

Slide 27

Slide 27 text

4. セキュリティを担保したpipelineの構築&運用 プラクティス

Slide 28

Slide 28 text

問題とモチベーション 問題： ・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を実行したい。

Slide 29

Slide 29 text

なんでSelf Hosted Agentにしたのか？ ・Azure DevOps ServicesのパブリックIPアドレス範囲をIP制限に追加する事で、実現 もできるが、変更の可能性が残る。

Slide 30

Slide 30 text

Self Hosted Agentによる環境イメージ 1. ・Azure DevOpsにパイプラインの定義。 2. ・VM上で登録されたAgentがジョブを実行。 3. ・AzureDevOpsには、VM上で実行された結果が返却される。 Azure DevOps Azure Container Registry Virtual Machine 同一ネットワーク job実行

Slide 31

Slide 31 text

Agentの作成方法 ※pipelineの作成とVM環境作成は既にされている事を想定して省略します。🙇 1. Personal Access Tokenの取得 2. PoolとAgentの作成とダウンロード

Slide 32

Slide 32 text

1.Personal Access Tokenの取得 Show all scopesを押下して、Agent Poolsにチェックを入れることを忘れずに。 最初見当たらずに焦りました w

Slide 33

Slide 33 text

2.1PoolとAgentの作成とダウンロード 「Add pool」を押下して、Pool typeは「Self-hosted」を選択して、任意の名前で作成します。

Slide 34

Slide 34 text

2.2PoolとAgentの作成とダウンロード 作成したPoolを選択し、Agentを作成します。 あとは、VM環境上で画像右の内容の通りに、 OS毎にダウンロードができるのでダウンロードをしてください。シェ ルを実行してウィザードに従って必要な設定を入力すれば OKです。

Slide 35

Slide 35 text

まとめ ・セキュアにというよりも、IP制限によってネットワーク制限がかけられた環境下でもパイ プラインを動作させる為の方法がわかった。 ・Azure DevOpsとAzure間できる事多い。（小並感）

Slide 36

Slide 36 text

Q&A