スケーラブル CI/CD with Nx モノレポ

by okmttdhr

Slide 1

Slide 1 text

スケーラブル CI/CD with Nx モノレポ okmttdhr

Slide 2

Slide 2 text

自己紹介 DMM プラットフォーム事業本部エンジニア YouTube アニメにハマっている

Slide 3

Slide 3 text

背景プラットフォーム事業本部は、認証・決済など横断的に使われる機能を提供するその中でもフロントエンドは、多くのプロダクトに対して少数のエンジニアで開発をしていた似たようなコードや仕組みを書く必要がある割に、なんのエコシステムも存在していなかった結果として、開発効率の悪さや、プログラムでもUI でも、統一感のなさが問題になっていた

Slide 4

Slide 4 text

=> フロントエンド開発を支えるスケーラブルなエコシステムが必要

Slide 5

Slide 5 text

=> モノレポを選択ひとつのプラットフォームチームを中心として多くのチームがFE 開発を進めていく組織体制にマッチする

Slide 6

Slide 6 text

Slide 7

Slide 7 text

一般的なモノレポの利点 - 簡単にコードを共有できる - アトミックなバージョン管理 - 技術スタックの統一

Slide 8

Slide 8 text

Nx とは元々はモノレポによらないビルドツール distributed task execution, computation caching, smart rebuilds of affected projects…

Slide 9

Slide 9 text

Nx によるモノレポ - 影響のあるアプリケーションだけをテスト、ビルド - Nx CLI による、複数のシステムでのコマンドラインの統一 - ローカルキャッシュによる高速なビルド - 依存関係のビジュアル化、etc

Slide 10

Slide 10 text

=> 従来のモノレポの欠点をカバー

Slide 11

Slide 11 text

モノレポに含まれるもの例

Slide 12

Slide 12 text

[ 本題] スケーラブルな CI/CD とは？ - 1. アプリケーションが増えても実行時間が速い - 2. アプリケーションが増えても保守できる - 3. チームが増えても疎結合に運用できる

Slide 13

Slide 13 text

1. アプリケーションが増えても実行時間が速い

Slide 14

Slide 14 text

1. アプリケーションが増えても実行時間が速い n = アプリケーション & ライブラリの数モノレポでないアプリでは n = 1 だが、モノレポでは理論上無限にアプリが増えるすべて直列だと、実行時間が n に比例して伸びるのでスケールしない ` ` ` ` ` `

Slide 15

Slide 15 text

=> アプリケーションが増えても、全体の CI/CD 実行時間に影響しないことが大事

Slide 16

Slide 16 text

1. アプリケーションが増えても実行時間が速い Nx で影響のあるアプリケーション & ライブラリを出力することができる nx affected:test --parallel などもあるが、それ以上のことをしたかったので不採用 ` ` $ nx affected:apps --base=origin/main --head=HEAD # 環境によって base, head は変更可能 > NX Affected apps: - app-foo - app-bar - app-buz $ nx affected:libs --base=origin/main --head=HEAD > NX Affected libs: - lib-foo - lib-bar - lib-buz

Slide 17

Slide 17 text

1. アプリケーションが増えても実行時間が速い出力したアプリケーション & ライブラリを Github Actions の matrix 形式に変換 composite action 化することで、使い回せるように 1. https://github.blog/changelog/2020-04-15-github-actions-new-workflow-features/ ↩︎ 2. https://docs.github.com/en/actions/creating-actions/creating-a-composite-action ↩︎ [1] ` `[2] name: output affected outputs: affected: description: 'affected apps and libs' value: ${{ steps.print.outputs.affected }} runs: using: composite steps: - name: print id: print run: | # affected-to-matrix.js で nx affected を実行し matrix 形式に変換 MATRIX=$(node ./scripts/affected-to-matrix.js) echo "::set-output name=affected::$MATRIX" shell: bash

Slide 18

Slide 18 text

1. アプリケーションが増えても実行時間が速い出力したアプリケーション & ライブラリを Github Actions の matrix 形式に変換 composite action 化することで、使い回せるように 1. https://github.blog/changelog/2020-04-15-github-actions-new-workflow-features/ ↩︎ 2. https://docs.github.com/en/actions/creating-actions/creating-a-composite-action ↩︎ [1] ` `[2] MATRIX=$(node ./scripts/affected-to-matrix.js) name: output affected outputs: affected: description: 'affected apps and libs' value: ${{ steps.print.outputs.affected }} runs: using: composite steps: - name: print id: print run: | # affected-to-matrix.js で nx affected を実行し matrix 形式に変換 echo "::set-output name=affected::$MATRIX" shell: bash

Slide 19

Slide 19 text

1. アプリケーションが増えても実行時間が速い出力したアプリケーション & ライブラリを Github Actions の matrix 形式に変換 composite action 化することで、使い回せるように 1. https://github.blog/changelog/2020-04-15-github-actions-new-workflow-features/ ↩︎ 2. https://docs.github.com/en/actions/creating-actions/creating-a-composite-action ↩︎ [1] ` `[2] using: composite name: output affected outputs: affected: description: 'affected apps and libs' value: ${{ steps.print.outputs.affected }} runs: steps: - name: print id: print run: | # affected-to-matrix.js で nx affected を実行し matrix 形式に変換 MATRIX=$(node ./scripts/affected-to-matrix.js) echo "::set-output name=affected::$MATRIX" shell: bash

Slide 20

Slide 20 text

Slide 21

Slide 21 text

1. アプリケーションが増えても実行時間が速い作成した composite action を使って、影響のあるアプリケーション & ライブラリだけをテスト ` ` name: test lint build # リントやビルドも合わせて行っているが、並列化の余地はある (swc 等も活用し、全部込みで5 分程度で終わるので今は問題に jobs: output-affected: runs-on: ubuntu-latest outputs: affected: ${{ steps.print.outputs.affected }} steps: - uses: ./.github/workflows/actions/output-affected id: print test-lint-build: runs-on: ubuntu-latest environment: test strategy: # 生成した matrix を設置 matrix: ${{needs.output-affected.outputs.affected}} steps: # 実際のテスト実行スクリプト ( 省略)

Slide 22

Slide 22 text

1. アプリケーションが増えても実行時間が速い作成した composite action を使って、影響のあるアプリケーション & ライブラリだけをテスト ` ` steps: - uses: ./.github/workflows/actions/output-affected id: print name: test lint build # リントやビルドも合わせて行っているが、並列化の余地はある (swc 等も活用し、全部込みで5 分程度で終わるので今は問題にな jobs: output-affected: runs-on: ubuntu-latest outputs: affected: ${{ steps.print.outputs.affected }} test-lint-build: runs-on: ubuntu-latest environment: test strategy: # 生成した matrix を設置 matrix: ${{needs.output-affected.outputs.affected}} steps: # 実際のテスト実行スクリプト ( 省略)

Slide 23

Slide 23 text

1. アプリケーションが増えても実行時間が速い作成した composite action を使って、影響のあるアプリケーション & ライブラリだけをテスト ` ` outputs: affected: ${{ steps.print.outputs.affected }} test-lint-build: strategy: # 生成した matrix を設置 matrix: ${{needs.output-affected.outputs.affected}} name: test lint build # リントやビルドも合わせて行っているが、並列化の余地はある (swc 等も活用し、全部込みで5 分程度で終わるので今は問題にな jobs: output-affected: runs-on: ubuntu-latest steps: - uses: ./.github/workflows/actions/output-affected id: print runs-on: ubuntu-latest environment: test steps: # 実際のテスト実行スクリプト ( 省略)

Slide 24

Slide 24 text

Slide 25

Slide 25 text

1. アプリケーションが増えても実行時間が速い影響のあるアプリケーション & ライブラリだけをデプロイ name: deploy jobs: output-affected: # 省略 call-testing: # 省略 call-deploy: needs: [output-affected, call-testing] runs-on: ubuntu-latest environment: ${{matrix.app-name}}-prd # environment によりアプリごとの環境変数を読み込める strategy: # 生成した matrix を設置 matrix: ${{fromJson(needs.output-affected.outputs.affected)}} steps: - uses: actions/checkout@v2 - uses: ./.github/workflows/actions/ecr-deploy with: app-name: ${{matrix.app-name}} AWS_ECR_ACCESS_KEY_ID: ${{secrets.AWS_ECR_ACCESS_KEY_ID}} AWS_ECR_SECRET_ACCESS_KEY: ${{secrets.AWS_ECR_SECRET_ACCESS_KEY}}

Slide 26

Slide 26 text

1. アプリケーションが増えても実行時間が速い影響のあるアプリケーション & ライブラリだけをデプロイ output-affected: # 省略 name: deploy jobs: call-testing: # 省略 call-deploy: needs: [output-affected, call-testing] runs-on: ubuntu-latest environment: ${{matrix.app-name}}-prd # environment によりアプリごとの環境変数を読み込める strategy: # 生成した matrix を設置 matrix: ${{fromJson(needs.output-affected.outputs.affected)}} steps: - uses: actions/checkout@v2 - uses: ./.github/workflows/actions/ecr-deploy with: app-name: ${{matrix.app-name}} AWS_ECR_ACCESS_KEY_ID: ${{secrets.AWS_ECR_ACCESS_KEY_ID}} AWS_ECR_SECRET_ACCESS_KEY: ${{secrets.AWS_ECR_SECRET_ACCESS_KEY}}

Slide 27

Slide 27 text

1. アプリケーションが増えても実行時間が速い影響のあるアプリケーション & ライブラリだけをデプロイ call-deploy: strategy: # 生成した matrix を設置 matrix: ${{fromJson(needs.output-affected.outputs.affected)}} app-name: ${{matrix.app-name}} name: deploy jobs: output-affected: # 省略 call-testing: # 省略 needs: [output-affected, call-testing] runs-on: ubuntu-latest environment: ${{matrix.app-name}}-prd # environment によりアプリごとの環境変数を読み込める steps: - uses: actions/checkout@v2 - uses: ./.github/workflows/actions/ecr-deploy with: AWS_ECR_ACCESS_KEY_ID: ${{secrets.AWS_ECR_ACCESS_KEY_ID}} AWS_ECR_SECRET_ACCESS_KEY: ${{secrets.AWS_ECR_SECRET_ACCESS_KEY}}

Slide 28

Slide 28 text

1. アプリケーションが増えても実行時間が速い影響のあるアプリケーション & ライブラリだけをデプロイ - uses: ./.github/workflows/actions/ecr-deploy name: deploy jobs: output-affected: # 省略 call-testing: # 省略 call-deploy: needs: [output-affected, call-testing] runs-on: ubuntu-latest environment: ${{matrix.app-name}}-prd # environment によりアプリごとの環境変数を読み込める strategy: # 生成した matrix を設置 matrix: ${{fromJson(needs.output-affected.outputs.affected)}} steps: - uses: actions/checkout@v2 with: app-name: ${{matrix.app-name}} AWS_ECR_ACCESS_KEY_ID: ${{secrets.AWS_ECR_ACCESS_KEY_ID}} AWS_ECR_SECRET_ACCESS_KEY: ${{secrets.AWS_ECR_SECRET_ACCESS_KEY}}

Slide 29

Slide 29 text

1. アプリケーションが増えても実行時間が速い影響のあるアプリケーション & ライブラリだけをデプロイ environment: ${{matrix.app-name}}-prd # environment によりアプリごとの環境変数を読み込める name: deploy jobs: output-affected: # 省略 call-testing: # 省略 call-deploy: needs: [output-affected, call-testing] runs-on: ubuntu-latest strategy: # 生成した matrix を設置 matrix: ${{fromJson(needs.output-affected.outputs.affected)}} steps: - uses: actions/checkout@v2 - uses: ./.github/workflows/actions/ecr-deploy with: app-name: ${{matrix.app-name}} AWS_ECR_ACCESS_KEY_ID: ${{secrets.AWS_ECR_ACCESS_KEY_ID}} AWS_ECR_SECRET_ACCESS_KEY: ${{secrets.AWS_ECR_SECRET_ACCESS_KEY}}

Slide 30

Slide 30 text

Slide 31

Slide 31 text

1. アプリケーションが増えても実行時間が速い影響のあるアプリケーション & ライブラリだけをデプロイ reusable workflow でテストを呼び出せる 1. https://docs.github.com/en/actions/learn-github-actions/reusing-workflows ↩︎ ` `[1] name: deploy jobs: output-affected: # 省略 call-testing: needs: [output-affected] uses: org/repo/.github/workflows/testing.yml@main with: app-name: ${{needs.output-affected.outputs.affected}} call-deploy: # 省略

Slide 32

Slide 32 text

1. アプリケーションが増えても実行時間が速い影響のあるアプリケーション & ライブラリだけをデプロイ reusable workflow でテストを呼び出せる 1. https://docs.github.com/en/actions/learn-github-actions/reusing-workflows ↩︎ ` `[1] output-affected: # 省略 name: deploy jobs: call-testing: needs: [output-affected] uses: org/repo/.github/workflows/testing.yml@main with: app-name: ${{needs.output-affected.outputs.affected}} call-deploy: # 省略

Slide 33

Slide 33 text

1. アプリケーションが増えても実行時間が速い影響のあるアプリケーション & ライブラリだけをデプロイ reusable workflow でテストを呼び出せる 1. https://docs.github.com/en/actions/learn-github-actions/reusing-workflows ↩︎ ` `[1] call-testing: uses: org/repo/.github/workflows/testing.yml@main app-name: ${{needs.output-affected.outputs.affected}} name: deploy jobs: output-affected: # 省略 needs: [output-affected] with: call-deploy: # 省略

Slide 34

Slide 34 text

Slide 35

Slide 35 text

1. アプリケーションが増えても実行時間が速い影響のあるアプリケーション & ライブラリだけの Storybook をデプロイ name: storybook jobs: output-affected: # 省略 call-storybook-build: needs: [output-affected] strategy: matrix: ${{fromJson(needs.output-affected.outputs.affected)}} steps: - uses: ./.github/workflows/actions/storybook-build with: app-name: ${{matrix.app-name}} call-storybook-comment: # 省略

Slide 36

Slide 36 text

1. アプリケーションが増えても実行時間が速い影響のあるアプリケーション & ライブラリだけの Storybook をデプロイ output-affected: # 省略 name: storybook jobs: call-storybook-build: needs: [output-affected] strategy: matrix: ${{fromJson(needs.output-affected.outputs.affected)}} steps: - uses: ./.github/workflows/actions/storybook-build with: app-name: ${{matrix.app-name}} call-storybook-comment: # 省略

Slide 37

Slide 37 text

1. アプリケーションが増えても実行時間が速い影響のあるアプリケーション & ライブラリだけの Storybook をデプロイ call-storybook-build: strategy: matrix: ${{fromJson(needs.output-affected.outputs.affected)}} app-name: ${{matrix.app-name}} name: storybook jobs: output-affected: # 省略 needs: [output-affected] steps: - uses: ./.github/workflows/actions/storybook-build with: call-storybook-comment: # 省略

Slide 38

Slide 38 text

Slide 39

Slide 39 text

1. アプリケーションが増えても実行時間が速い影響のあるアプリケーション & ライブラリだけの Storybook をPR にコメントエンジニアやデザイナーが影響範囲を容易に把握できる

Slide 40

Slide 40 text

1. アプリケーションが増えても実行時間が速い✅ ( 理論上) n = アプリケーションがどれだけふえても、実行時間に影響はない CI/CD 実行時間は、最も実行時間の長いアプリとほぼ等しくなる 1. 仮にボトルネックとなるアプリが現れた場合もまだまだ並列化の余地がある ↩︎ ` ` [1]

Slide 41

Slide 41 text

2. アプリケーションが増えても保守できる

Slide 42

Slide 42 text

2. アプリケーションが増えても保守できる n = アプリケーション & ライブラリの数モノレポでないアプリでは n = 1 だが、モノレポでは理論上無限にアプリが増えるすべて個別に CI/CD のコードを書いていると複雑化するし、スケールしない ` ` ` `

Slide 43

Slide 43 text

=> アプリケーションが増えても、統一されたパイプラインを使えることが重要

Slide 44

Slide 44 text

2. アプリケーションが増えても保守できる 2.1. 技術スタックの統一 Next.js を Docker image として ECS 環境へデプロイ ( 将来的にはインフラ側もこちらで用意した環境を提供したい) テスト、リント、型チェックなどは統一

Slide 45

Slide 45 text

2. アプリケーションが増えても保守できる 2.2. GitHub Actions を使いこなす reusable workflow , composite actions で共通のフローを切り出し適切にモジュール化し、低コストで複数のアプリケーションでの CI/CD パイプラインを運用 ` ` ` `

Slide 46

Slide 46 text

2. アプリケーションが増えても保守できる✅ n = アプリケーションがどれだけふえても、統一されたパイプラインを同じ yaml のコードで管理すれば良い ` `

Slide 47

Slide 47 text

3. チームが増えても疎結合に運用できる

Slide 48

Slide 48 text

3. チームが増えても疎結合に運用できる n = 関わるチームの数モノレポ上で開発するチームが増えるたびコミュニケーションコストが上がるようだとスケールしない ` `

Slide 49

Slide 49 text

=> チームが増えても、互いに疎結合な開発ができることが重要

Slide 50

Slide 50 text

3. チームが増えても疎結合に運用できる GitHub Flow でブランチ運用の統一 (rc = master, stg = tag, production = tag release)

Slide 51

Slide 51 text

3. チームが増えても疎結合に運用できる Hotfix のユースケースも考慮 ( 複数のチームがそれぞれのアプリケーションを検証中の場合、単純な revert だと他のチームに影響がでてしまうため)

Slide 52

Slide 52 text

3. チームが増えても疎結合に運用できる各ロールごとに、だれがなににオーナーシップを持つのかを定義実装者レビュワーマージアプリの新規作成エコシステム開発者エコシステム開発者エコシステム開発者アプリの機能開発/ 運用アプリの開発者アプリの開発者 & ( 一部) エコシステム開発者アプリの開発者共通ライブラリの新規作成エコシステム開発者エコシステム開発者エコシステム開発者共通ライブラリの機能開発/ 運用エコシステム開発者エコシステム開発者エコシステム開発者障害時の切り戻し … … … renovate … … … etc … … …

Slide 53

Slide 53 text

3. チームが増えても疎結合に運用できる CODEOWNERS の活用により自動化 # CODEOWNERS * @platform-team */app-foo/** @app-foo-team @platform-team */app-bar/** @app-bar-team @platform-team */lib-bar/** @platform-team */lib-bar/** @platform-team

Slide 54

Slide 54 text

3. チームが増えても疎結合に運用できる依存関係を Lint できるため、適切でないライブラリの使用を制限できる { "rules": { "@nrwl/nx/enforce-module-boundaries": [ "error", { "enforceBuildableLibDependency": true, "depConstraints": [ { "sourceTag": "scope:app-foo", "onlyDependOnLibsWithTags": [ "scope:component-library", "scope:logger" ] }, ] } ] } }

Slide 55

Slide 55 text

3. チームが増えても疎結合に運用できる依存関係を Lint できるため、適切でないライブラリの使用を制限できる "depConstraints": [ { "sourceTag": "scope:app-foo", "onlyDependOnLibsWithTags": [ "scope:component-library", "scope:logger" ] }, ] { "rules": { "@nrwl/nx/enforce-module-boundaries": [ "error", { "enforceBuildableLibDependency": true, } ] } }

Slide 56

Slide 56 text

3. チームが増えても疎結合に運用できる依存関係を Lint できるため、適切でないライブラリの使用を制限できる "sourceTag": "scope:app-foo", { "rules": { "@nrwl/nx/enforce-module-boundaries": [ "error", { "enforceBuildableLibDependency": true, "depConstraints": [ { "onlyDependOnLibsWithTags": [ "scope:component-library", "scope:logger" ] }, ] } ] } }

Slide 57

Slide 57 text

3. チームが増えても疎結合に運用できる依存関係を Lint できるため、適切でないライブラリの使用を制限できる "onlyDependOnLibsWithTags": [ "scope:component-library", "scope:logger" ] { "rules": { "@nrwl/nx/enforce-module-boundaries": [ "error", { "enforceBuildableLibDependency": true, "depConstraints": [ { "sourceTag": "scope:app-foo", }, ] } ] } }

Slide 58

Slide 58 text

Slide 59

Slide 59 text

3. チームが増えても疎結合に運用できる [coming soon] 依存関係のビジュアライズ (Nx Project Graph)

Slide 60

Slide 60 text

3. チームが増えても疎結合に運用できる✅ n = チームがどれだけふえても、疎結合に開発ができる ` `

Slide 61

Slide 61 text

まとめ

Slide 62

Slide 62 text

スケーラブルな CI/CD - 1. アプリケーションが増えても実行時間が速い - 2. アプリケーションが増えても保守できる - 3. チームが増えても疎結合に運用できる

Slide 63

Slide 63 text

スケーラブルな CI/CD - 1. アプリケーションが増えても実行時間が速い✅ Nx で影響のあるアプリケーションだけを並列で CI/CD - 2. アプリケーションが増えても保守できる - 3. チームが増えても疎結合に運用できる

Slide 64

Slide 64 text

スケーラブルな CI/CD - 1. アプリケーションが増えても実行時間が速い✅ Nx で影響のあるアプリケーションだけを並列で CI/CD - 2. アプリケーションが増えても保守できる✅ 技術スタックの統一 reusable workflow , composite actions - 3. チームが増えても疎結合に運用できる ` ` ` `

Slide 65

Slide 65 text

スケーラブルな CI/CD - 1. アプリケーションが増えても実行時間が速い✅ Nx で影響のあるアプリケーションだけを並列で CI/CD - 2. アプリケーションが増えても保守できる✅ 技術スタックの統一 reusable workflow , composite actions - 3. チームが増えても疎結合に運用できる✅ ブランチ運用の統一 CODEOWNERS の活用依存関係の Lint ` ` ` `

Slide 66

Slide 66 text

スケーラブルな CI/CD ✅ - 1. アプリケーションが増えても実行時間が速い✅ Nx で影響のあるアプリケーションだけを並列で CI/CD - 2. アプリケーションが増えても保守できる✅ 技術スタックの統一 reusable workflow , composite actions - 3. チームが増えても疎結合に運用できる✅ ブランチ運用の統一 CODEOWNERS の活用依存関係の Lint ` ` ` `

Slide 67

Slide 67 text

=> まだまだフロントエンドエコシステムで解決したい課題がたくさんあります https://dmm-corp.com/recruit/engineer/946/ https://dmm-corp.com/recruit/designer/970/

Slide 68

Slide 68 text

ご清聴ありがとうございました