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.3k
DMMアカウントサービスのフロントエンド改善
okmttdhr
2
730
LambdaとDynamoDBでIoTバックエンド開発
okmttdhr
0
98
Other Decks in Programming
See All in Programming
Effective Signals in Angular 19+: Rules and Helpers @ngbe2024
manfredsteyer
PRO
0
140
短期間での新規プロダクト開発における「コスパの良い」Goのテスト戦略」 / kamakura.go
n3xem
2
170
テストケースの名前はどうつけるべきか?
orgachem
PRO
0
130
ブラウザ単体でmp4書き出すまで - muddy-web - 2024-12
yue4u
3
470
PHPUnitしか使ってこなかった 一般PHPerがPestに乗り換えた実録
mashirou1234
0
190
rails statsで大解剖 🔍 “B/43流” のRailsの育て方を歴史とともに振り返ります
shoheimitani
2
930
Beyond ORM
77web
6
780
Zoneless Testing
rainerhahnekamp
0
120
Scalaから始めるOpenFeature入門 / Scalaわいわい勉強会 #4
arthur1
1
330
Go の GC の不得意な部分を克服したい
taiyow
3
790
return文におけるstd::moveについて
onihusube
1
1.1k
rails stats で紐解く ANDPAD のイマを支える技術たち
andpad
1
290
Featured
See All Featured
Optimizing for Happiness
mojombo
376
70k
Building an army of robots
kneath
302
44k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.2k
Designing for humans not robots
tammielis
250
25k
Docker and Python
trallard
42
3.1k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
28
4.4k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Keith and Marios Guide to Fast Websites
keithpitt
410
22k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
Designing Experiences People Love
moore
138
23k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
29
2k
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/
ご清聴ありがとうございました