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
サーバサイドTypeScriptモノレポを半年運用した結果/How to maintain s...
Search
tom-256
October 30, 2022
Programming
460
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
サーバサイドTypeScriptモノレポを半年運用した結果/How to maintain server side typescript monorepo
Kanazawa.js #24
tom-256
October 30, 2022
More Decks by tom-256
See All by tom-256
PipeCDを導入してリリースフローを改善した話/How to improve release workflow by pipecd
tom256
0
61
フロントエンドのCIについて/front end ci tips
tom256
0
100
レガシーなAnsibleを改善していくための方針/How to improve the legacy Ansible
tom256
10
2.7k
Slack + Cloud Functionsで迅速な障害の初動対応をする/incident management by slack
tom256
0
180
AWSで実現するChatOps〜サーバレスでBlue/Greenデプロイする仕組みと工夫点〜 /chatops deployment
tom256
0
420
GHEとAWSを使用したデプロイ/リリースフローの紹介/introduction-deployflow-aws-and-ghe
tom256
0
160
Other Decks in Programming
See All in Programming
『コードを書く以外の』エンジニアリング〜課金基盤移行プロジェクト推進のためのTips4選
yuriko1211
0
580
OpenSpecのproposalにbrainstormingを持たせてみた
tigertora7571
1
200
AI時代、エンジニアはどう育つのか -未経験エンジニアの成長を間近で見て考えたこと-
thasu0123
0
220
AWS DevOps AgentのAzure接続機能を検証して見えた活用法/Use Cases Verified for the AWS DevOps Agent's Azure Connectivity Feature
masakiokuda
1
220
変わらないものが、変わるものを決める — 意図駆動開発 × イベントソーシング × イミュータブル | What Doesn't Change Decides What Can — IDD × Event Sourcing × Immutability
tomohisa
0
1.3k
琵琶湖の水は止められてもNet--HTTPのリトライは止められない / You might be able to stop the water flow of Lake Biwa but you can't stop Net::HTTP retries
luccafort
PRO
0
590
型も通る、synthも通る、それでも危ない 〜AIのCDKの権限とコストを機械で検証する〜 / It Passes Type Checks, It Passes Synth Checks, but It’s Still Risky — Automatically Verifying Permissions and Costs in AI’s CDK —
seike460
PRO
1
540
AI時代に設計が 最大の生産性レバーになる 意図駆動開発とデータを消さない設計|Don't Delete Your Data or Your Intent — Design as the Deepest Lever in the AI Era
tomohisa
1
710
ITヒヤリハットを整理してみた ~ライフサイクルと原因から考える再発防止策~
koukimiura
1
140
freee が目指す データ マネジメント戦略 AI-Ready 時代を支える 攻めのガバナンスとは
freee
PRO
0
280
言語を使う側から、作る側へ。 自作 Lisp で得た新たな気づき。
andpad
0
150
PHP に部分適用が来るぞ!……ところで何それ?おいしいの? #phpcon / phpcon-2026
shogogg
0
580
Featured
See All Featured
The untapped power of vector embeddings
frankvandijk
2
1.8k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
11
980
JAMstack: Web Apps at Ludicrous Speed - All Things Open 2022
reverentgeek
1
540
How To Speak Unicorn (iThemes Webinar)
marktimemedia
1
520
Balancing Empowerment & Direction
lara
6
1.2k
Thoughts on Productivity
jonyablonski
76
5.3k
The World Runs on Bad Software
bkeepers
PRO
72
12k
KATA
mclloyd
PRO
35
15k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
508
140k
Building Experiences: Design Systems, User Experience, and Full Site Editing
marktimemedia
0
570
Gemini Prompt Engineering: Practical Techniques for Tangible AI Outcomes
mfonobong
2
480
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.7k
Transcript
サーバサイド TypeScript モノレポを半 年運用した結果 Kanazawa.js #24 1
@tom-256 SRE/Backend 2
今日話すこと モノレポのメリット 現状の共有、工夫点 課題点 まとめ 3
モノレポのメリット コラボレーション... 意識しなくてもコード、PR 、会話が目に入る 視認性... プロダクトコードはすべてここにある状態 リポジトリ全体のコントール性が高い... 規約、ビルド、作業レバレ ッジ 4
機能面はGitHub の機能を使うとポリレポでもモノレポと近いメリット が得られる Template Repository( パッケージのテンプレート) GitHub Actions Reusable Workflow(CI
ワークフローの共通化) GitHub Actions Repository Dispatch( リポジトリ間のCI トリガー) npm package による設定ファイルの共通化 5
現状の共有 6
工夫点 設定ファイルの共通化 Makefile ESLint コミット規約 CI 7
設定ファイルの共通化 jest tsconfig など ディレクトリ構成 packages/config 利用側 "@tom-256/config": "*", 8
Makefile make init-service NAME='foo' アプリケーションディレクトリ作成 各種設定ファイル追加 要件が増えてきて手作業が出始めるので都度改修が必要 9
ESLint インポートに関する規約(import/no-restricted-paths) API サーバ間の相互依存を禁止 共通package は許容 アプリケーション設計の規約にも利用 ファイル名、ディレクトリ名の規約 10
パフォーマンス調査方法をブログにまとめた ESLint のパフォーマンスを調査する tom-256.log 開発が進むに連れ増えていくのでCI などで定期的に計測して検知する 仕組みが必要 11
コミット規約 Conventional Commits を採用 @commitlint/config-lerna-scopes を使用し、コミットメッセージにモ ノレポのパッケージ名を含めることで、フィルタが可能に 12
例: ディレクトリ構成 packages ├── hoge └── fuga コミットメッセージ feat(hoge): hogefuga
hogefuga 13
CI docker/build-push-action とmatrix strategy により動的なCI 構築 変更があったパッケージのみCI 実施 パッケージが増えてもCI 時間が増加しないように
unit test... キャッシュ未導入、テスト用パッケージが重い問題 docker build...multistage build,gha cache 14
actions/labeler でパッケージごとのラベルを作成 amannn/action-semantic-pull-request でPR タイトルを統一 ArtiomTr/jest-coverage-report-action でテストカバレッジ表示 15
課題点 Dockerfile コードジェネレーター Renovate フレームワーク 可視化 16
Dockerfile 共通のイメージを使いたいという要件から現状1 つのDockerfile コンテキストを小さく保つためDockerfile を分割したい COPY 対象 パイプラインのトリガー 17
. ├── Dockerfile └── apps ├── foo └── bar └──
apps ├── foo │ └── Dockerfile └── bar └── Dockerfile 18
コードジェネレーター 要件が増えてきて手作業が出始めるので都度改修が必要 パッケージの設定ファイルが各所に散らばってしまう 19
Renovate パッケージ更新を自動化 CODEOWNERS グルーピング 20
フレームワーク フレームワークに依存するのを避けるため導入しなかったが結局必要 な要件が出てきた 初期構築コストが無駄になってしまった TypeScript に統一...Turborepo 多言語も考慮...Nx 21
可視化 変化があったら知りたい 実行時間 test lint build docker build npm ci
Docker イメージサイズ 22
開発体制 開発体制はフィーチャーチーム DX 面にオーナーシップを持つメンバーが固定化 ローカル開発環境 Test 、Lint 、Build ライブラリバージョンアップ CI
23
まとめ 現状 簡単に同じ設定のアプリケーションをセットアップできる TypeScript は初期構築コストが高い 開発に関する規約を設定 アプリケーションが増えてもCI の時間が増えないように実装 24
感想 ESLint やCommit Hook で規約を作りやすい Developer Experience 、CI 面の負債をまとめて返しやすい 自分が触っていないコードが目に入りやすい
25