Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
サーバサイド TypeScript モノレポを半 年運用した結果 Kanazawa.js #24 1
Slide 2
Slide 2 text
@tom-256 SRE/Backend 2
Slide 3
Slide 3 text
今日話すこと モノレポのメリット 現状の共有、工夫点 課題点 まとめ 3
Slide 4
Slide 4 text
モノレポのメリット コラボレーション... 意識しなくてもコード、PR 、会話が目に入る 視認性... プロダクトコードはすべてここにある状態 リポジトリ全体のコントール性が高い... 規約、ビルド、作業レバレ ッジ 4
Slide 5
Slide 5 text
機能面はGitHub の機能を使うとポリレポでもモノレポと近いメリット が得られる Template Repository( パッケージのテンプレート) GitHub Actions Reusable Workflow(CI ワークフローの共通化) GitHub Actions Repository Dispatch( リポジトリ間のCI トリガー) npm package による設定ファイルの共通化 5
Slide 6
Slide 6 text
現状の共有 6
Slide 7
Slide 7 text
工夫点 設定ファイルの共通化 Makefile ESLint コミット規約 CI 7
Slide 8
Slide 8 text
設定ファイルの共通化 jest tsconfig など ディレクトリ構成 packages/config 利用側 "@tom-256/config": "*", 8
Slide 9
Slide 9 text
Makefile make init-service NAME='foo' アプリケーションディレクトリ作成 各種設定ファイル追加 要件が増えてきて手作業が出始めるので都度改修が必要 9
Slide 10
Slide 10 text
ESLint インポートに関する規約(import/no-restricted-paths) API サーバ間の相互依存を禁止 共通package は許容 アプリケーション設計の規約にも利用 ファイル名、ディレクトリ名の規約 10
Slide 11
Slide 11 text
パフォーマンス調査方法をブログにまとめた ESLint のパフォーマンスを調査する tom-256.log 開発が進むに連れ増えていくのでCI などで定期的に計測して検知する 仕組みが必要 11
Slide 12
Slide 12 text
コミット規約 Conventional Commits を採用 @commitlint/config-lerna-scopes を使用し、コミットメッセージにモ ノレポのパッケージ名を含めることで、フィルタが可能に 12
Slide 13
Slide 13 text
例: ディレクトリ構成 packages ├── hoge └── fuga コミットメッセージ feat(hoge): hogefuga hogefuga 13
Slide 14
Slide 14 text
CI docker/build-push-action とmatrix strategy により動的なCI 構築 変更があったパッケージのみCI 実施 パッケージが増えてもCI 時間が増加しないように unit test... キャッシュ未導入、テスト用パッケージが重い問題 docker build...multistage build,gha cache 14
Slide 15
Slide 15 text
actions/labeler でパッケージごとのラベルを作成 amannn/action-semantic-pull-request でPR タイトルを統一 ArtiomTr/jest-coverage-report-action でテストカバレッジ表示 15
Slide 16
Slide 16 text
課題点 Dockerfile コードジェネレーター Renovate フレームワーク 可視化 16
Slide 17
Slide 17 text
Dockerfile 共通のイメージを使いたいという要件から現状1 つのDockerfile コンテキストを小さく保つためDockerfile を分割したい COPY 対象 パイプラインのトリガー 17
Slide 18
Slide 18 text
. ├── Dockerfile └── apps ├── foo └── bar └── apps ├── foo │ └── Dockerfile └── bar └── Dockerfile 18
Slide 19
Slide 19 text
コードジェネレーター 要件が増えてきて手作業が出始めるので都度改修が必要 パッケージの設定ファイルが各所に散らばってしまう 19
Slide 20
Slide 20 text
Renovate パッケージ更新を自動化 CODEOWNERS グルーピング 20
Slide 21
Slide 21 text
フレームワーク フレームワークに依存するのを避けるため導入しなかったが結局必要 な要件が出てきた 初期構築コストが無駄になってしまった TypeScript に統一...Turborepo 多言語も考慮...Nx 21
Slide 22
Slide 22 text
可視化 変化があったら知りたい 実行時間 test lint build docker build npm ci Docker イメージサイズ 22
Slide 23
Slide 23 text
開発体制 開発体制はフィーチャーチーム DX 面にオーナーシップを持つメンバーが固定化 ローカル開発環境 Test 、Lint 、Build ライブラリバージョンアップ CI 23
Slide 24
Slide 24 text
まとめ 現状 簡単に同じ設定のアプリケーションをセットアップできる TypeScript は初期構築コストが高い 開発に関する規約を設定 アプリケーションが増えてもCI の時間が増えないように実装 24
Slide 25
Slide 25 text
感想 ESLint やCommit Hook で規約を作りやすい Developer Experience 、CI 面の負債をまとめて返しやすい 自分が触っていないコードが目に入りやすい 25