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.2k
スケーラブル CI/CD with Nx モノレポ
okmttdhr
December 08, 2021
Tweet
Share
More Decks by okmttdhr
See All by okmttdhr
フロントエンドエコシステムで効率化する組織開発
okmttdhr
4
9.5k
DMMアカウントサービスのフロントエンド改善
okmttdhr
2
740
LambdaとDynamoDBでIoTバックエンド開発
okmttdhr
0
110
Other Decks in Programming
See All in Programming
ニックトレイン登壇資料
ryotakurokawa
0
140
신입 안드로이드 개발자의 AI 스타트업 생존기 (+ Native C++ Code를 Android에서 사용해보기)
dygames
0
500
php-fpm がリクエスト処理する仕組みを追う / Tracing-How-php-fpm-Handles-Requests
shin1x1
5
820
AI時代のプログラミング教育 / programming education in ai era
kishida
23
20k
20250326_生成AIによる_レビュー承認システムの実現.pdf
takahiromatsui
17
5.5k
SLI/SLOの設定を進めるその前に アラート品質の改善に取り組んだ話
tanden
2
730
ローコードサービスの進化のためのモノレポ移行
taro28
1
330
보일러플레이트 코드가 진짜 나쁜 건가요?
gaeun5744
0
370
AtCoder Heuristic First-step Vol.1 講義スライド
terryu16
2
1k
Devin , 正しい付き合い方と使い方 / Living and Working with Devin
yukinagae
1
530
RCPと宣言型ポリシーについてのお話し
kokitamura
2
150
Denoでフロントエンド開発 2025年春版 / Frontend Development with Deno (Spring 2025)
petamoriken
1
1.3k
Featured
See All Featured
The MySQL Ecosystem @ GitHub 2015
samlambert
251
12k
Documentation Writing (for coders)
carmenintech
69
4.7k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
8
700
The Cost Of JavaScript in 2023
addyosmani
48
7.6k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
Producing Creativity
orderedlist
PRO
344
40k
The World Runs on Bad Software
bkeepers
PRO
67
11k
Making the Leap to Tech Lead
cromwellryan
133
9.2k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Building Adaptive Systems
keathley
41
2.5k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
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/
ご清聴ありがとうございました