Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
スケーラブル CI/CD with Nx モノレポ
Search
okmttdhr
December 08, 2021
Programming
5
2.3k
スケーラブル CI/CD with Nx モノレポ
okmttdhr
December 08, 2021
Tweet
Share
More Decks by okmttdhr
See All by okmttdhr
フロントエンドエコシステムで効率化する組織開発
okmttdhr
4
9.6k
DMMアカウントサービスのフロントエンド改善
okmttdhr
2
760
LambdaとDynamoDBでIoTバックエンド開発
okmttdhr
0
120
Other Decks in Programming
See All in Programming
関数型まつり2025登壇資料「関数プログラミングと再帰」
taisontsukada
2
840
Select API from Kotlin Coroutine
jmatsu
1
180
アンドパッドの Go 勉強会「 gopher 会」とその内容の紹介
andpad
0
250
AIネイティブなプロダクトをGolangで挑む取り組み
nmatsumoto4
0
120
Haskell でアルゴリズムを抽象化する / 関数型言語で競技プログラミング
naoya
17
4.8k
Spring gRPC で始める gRPC 入門 / Introduction to gRPC with Spring gRPC
mackey0225
2
520
Enterprise Web App. Development (2): Version Control Tool Training Ver. 5.1
knakagawa
1
120
すべてのコンテキストを、 ユーザー価値に変える
applism118
0
190
CursorはMCPを使った方が良いぞ
taigakono
0
120
コードの90%をAIが書く世界で何が待っているのか / What awaits us in a world where 90% of the code is written by AI
rkaga
41
27k
KotlinConf 2025 現地で感じたServer-Side Kotlin
n_takehata
1
220
単体テストの始め方/作り方
toms74209200
0
510
Featured
See All Featured
It's Worth the Effort
3n
184
28k
Scaling GitHub
holman
459
140k
Embracing the Ebb and Flow
colly
86
4.7k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
Fireside Chat
paigeccino
37
3.5k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Making Projects Easy
brettharned
116
6.2k
Mobile First: as difficult as doing things right
swwweet
223
9.7k
GitHub's CSS Performance
jonrohan
1031
460k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.6k
Making the Leap to Tech Lead
cromwellryan
134
9.3k
Transcript
スケーラブル CI/CD with Nx モノレポ okmttdhr
自己紹介 DMM プラットフォーム事業本部エンジニア YouTube アニメにハマっている
背景 プラットフォーム事業本部は、認証・決済など横断的に使われる機能を提供する その中でもフロントエンドは、多くのプロダクトに対して少数のエンジニアで開発をしていた 似たようなコードや仕組みを書く必要がある割に、なんのエコシステムも存在していなかった 結果として、開発効率の悪さや、プログラムでもUI でも、統一感のなさが問題になっていた
=> フロントエンド開発を支える スケーラブルなエコシステムが必要
=> モノレポを選択 ひとつのプラットフォームチームを中心として 多くのチームがFE 開発を進めていく組織体制にマッチする
Nx
一般的なモノレポの利点 - 簡単にコードを共有できる - アトミックなバージョン管理 - 技術スタックの統一
Nx とは 元々はモノレポによらないビルドツール distributed task execution, computation caching, smart rebuilds
of affected projects…
Nx によるモノレポ - 影響のあるアプリケーションだけをテスト、ビルド - Nx CLI による、複数のシステムでのコマンドラインの統一 - ローカルキャッシュによる高速なビルド
- 依存関係のビジュアル化、etc
=> 従来のモノレポの欠点をカバー
モノレポに含まれるもの 例
[ 本題] スケーラブルな CI/CD とは? - 1. アプリケーションが増えても 実行時間が速い -
2. アプリケーションが増えても 保守できる - 3. チームが増えても 疎結合に運用できる
1. アプリケーションが増えても 実行時間が速い
1. アプリケーションが増えても 実行時間が速い n = アプリケーション & ライブラリの数 モノレポでないアプリでは n
= 1 だが、モノレポでは理論上無限にアプリが増える すべて直列だと、実行時間が n に比例して伸びるのでスケールしない ` ` ` ` ` `
=> アプリケーションが増えても、全体の CI/CD 実行 時間に影響しないことが大事
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
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
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
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
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
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: # 実際のテスト実行スクリプト ( 省略)
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: # 実際のテスト実行スクリプト ( 省略)
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: # 実際のテスト実行スクリプト ( 省略)
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: # 実際のテスト実行スクリプト ( 省略)
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}}
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}}
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}}
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}}
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}}
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}}
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: # 省略
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: # 省略
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: # 省略
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: # 省略
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: # 省略
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: # 省略
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: # 省略
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: # 省略
1. アプリケーションが増えても 実行時間が速い 影響のあるアプリケーション & ライブラリだけの Storybook をPR にコメント エンジニアやデザイナーが影響範囲を容易に把握できる
1. アプリケーションが増えても 実行時間が速い✅ ( 理論上) n = アプリケーション がどれだけふえても、実行時間に影響はない CI/CD
実行時間は、最も実行時間の長いアプリとほぼ等しくなる 1. 仮にボトルネックとなるアプリが現れた場合もまだまだ並列化の余地がある ↩︎ ` ` [1]
2. アプリケーションが増えても 保守できる
2. アプリケーションが増えても 保守できる n = アプリケーション & ライブラリの数 モノレポでないアプリでは n
= 1 だが、モノレポでは理論上無限にアプリが増える すべて個別に CI/CD のコードを書いていると複雑化するし、スケールしない ` ` ` `
=> アプリケーションが増えても、統一されたパイプ ラインを使えることが重要
2. アプリケーションが増えても 保守できる 2.1. 技術スタックの統一 Next.js を Docker image として
ECS 環境へデプロイ ( 将来的にはインフラ側もこちらで用意した環境を提 供したい) テスト、リント、型チェックなどは統一
2. アプリケーションが増えても 保守できる 2.2. GitHub Actions を使いこなす reusable workflow ,
composite actions で共通のフローを切り出し 適切にモジュール化し、低コストで複数のアプリケーションでの CI/CD パイプラインを運用 ` ` ` `
2. アプリケーションが増えても 保守できる✅ n = アプリケーション がどれだけふえても、統一されたパイプラインを同じ yaml のコードで管理すれば 良い
` `
3. チームが増えても 疎結合に運用できる
3. チームが増えても 疎結合に運用できる n = 関わるチームの数 モノレポ上で開発するチームが増えるたびコミュニケーションコストが上がるようだとスケールしない ` `
=> チームが増えても、互いに疎結合な開発ができる ことが重要
3. チームが増えても 疎結合に運用できる GitHub Flow でブランチ運用の統一 (rc = master, stg
= tag, production = tag release)
3. チームが増えても 疎結合に運用できる Hotfix のユースケースも考慮 ( 複数のチームがそれぞれのアプリケーションを検証中の場合、単純な revert だと他のチームに影響がでてしまうため)
3. チームが増えても 疎結合に運用できる 各ロールごとに、だれがなににオーナーシップを持つのかを定義 実装者 レビュワー マージ アプリの新規作成 エコシステム開発者 エコシステム開発者
エコシステム開発者 アプリの機能開発/ 運用 アプリの開発者 アプリの開発者 & ( 一部) エコシステム開発者 アプリの開発者 共通ライブラリの新規作成 エコシステム開発者 エコシステム開発者 エコシステム開発者 共通ライブラリの機能開発/ 運用 エコシステム開発者 エコシステム開発者 エコシステム開発者 障害時の切り戻し … … … renovate … … … etc … … …
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
3. チームが増えても 疎結合に運用できる 依存関係を Lint できるため、適切でないライブラリの使用を制限できる { "rules": { "@nrwl/nx/enforce-module-boundaries":
[ "error", { "enforceBuildableLibDependency": true, "depConstraints": [ { "sourceTag": "scope:app-foo", "onlyDependOnLibsWithTags": [ "scope:component-library", "scope:logger" ] }, ] } ] } }
3. チームが増えても 疎結合に運用できる 依存関係を Lint できるため、適切でないライブラリの使用を制限できる "depConstraints": [ { "sourceTag":
"scope:app-foo", "onlyDependOnLibsWithTags": [ "scope:component-library", "scope:logger" ] }, ] { "rules": { "@nrwl/nx/enforce-module-boundaries": [ "error", { "enforceBuildableLibDependency": true, } ] } }
3. チームが増えても 疎結合に運用できる 依存関係を Lint できるため、適切でないライブラリの使用を制限できる "sourceTag": "scope:app-foo", { "rules":
{ "@nrwl/nx/enforce-module-boundaries": [ "error", { "enforceBuildableLibDependency": true, "depConstraints": [ { "onlyDependOnLibsWithTags": [ "scope:component-library", "scope:logger" ] }, ] } ] } }
3. チームが増えても 疎結合に運用できる 依存関係を Lint できるため、適切でないライブラリの使用を制限できる "onlyDependOnLibsWithTags": [ "scope:component-library", "scope:logger"
] { "rules": { "@nrwl/nx/enforce-module-boundaries": [ "error", { "enforceBuildableLibDependency": true, "depConstraints": [ { "sourceTag": "scope:app-foo", }, ] } ] } }
3. チームが増えても 疎結合に運用できる 依存関係を Lint できるため、適切でないライブラリの使用を制限できる { "rules": { "@nrwl/nx/enforce-module-boundaries":
[ "error", { "enforceBuildableLibDependency": true, "depConstraints": [ { "sourceTag": "scope:app-foo", "onlyDependOnLibsWithTags": [ "scope:component-library", "scope:logger" ] }, ] } ] } }
3. チームが増えても 疎結合に運用できる [coming soon] 依存関係のビジュアライズ (Nx Project Graph)
3. チームが増えても 疎結合に運用できる✅ n = チーム がどれだけふえても、疎結合に開発ができる ` `
まとめ
スケーラブルな CI/CD - 1. アプリケーションが増えても 実行時間が速い - 2. アプリケーションが増えても 保守できる
- 3. チームが増えても 疎結合に運用できる
スケーラブルな CI/CD - 1. アプリケーションが増えても 実行時間が速い✅ Nx で影響のあるアプリケーションだけを並列で CI/CD -
2. アプリケーションが増えても 保守できる - 3. チームが増えても 疎結合に運用できる
スケーラブルな CI/CD - 1. アプリケーションが増えても 実行時間が速い✅ Nx で影響のあるアプリケーションだけを並列で CI/CD -
2. アプリケーションが増えても 保守できる✅ 技術スタックの統一 reusable workflow , composite actions - 3. チームが増えても 疎結合に運用できる ` ` ` `
スケーラブルな CI/CD - 1. アプリケーションが増えても 実行時間が速い✅ Nx で影響のあるアプリケーションだけを並列で CI/CD -
2. アプリケーションが増えても 保守できる✅ 技術スタックの統一 reusable workflow , composite actions - 3. チームが増えても 疎結合に運用できる✅ ブランチ運用の統一 CODEOWNERS の活用 依存関係の Lint ` ` ` `
スケーラブルな CI/CD ✅ - 1. アプリケーションが増えても 実行時間が速い✅ Nx で影響のあるアプリケーションだけを並列で CI/CD
- 2. アプリケーションが増えても 保守できる✅ 技術スタックの統一 reusable workflow , composite actions - 3. チームが増えても 疎結合に運用できる✅ ブランチ運用の統一 CODEOWNERS の活用 依存関係の Lint ` ` ` `
=> まだまだフロントエンドエコシステムで 解決したい課題がたくさんあります https://dmm-corp.com/recruit/engineer/946/ https://dmm-corp.com/recruit/designer/970/
ご清聴ありがとうございました