CI/CD改善はポートフォリオで見せやすい
ポートフォリオでは、機能だけを見せる人が多いです。しかし、実務では開発の進め方も見られます。
CI/CDを導入し、さらに処理時間まで改善した記録があると、「現場の開発速度まで考えられる人」に見えます。
未経験や転職準備中でも、CI/CD改善は自分のリポジトリで実践しやすいテーマです。
最初は小さく入れる
最初から完璧なCI/CDを作る必要はありません。
最初の構成:
Pull Request:
lint
typecheck
test
build
main:
deploy
これだけで、最低限の品質チェックとデプロイ自動化が見せられます。
README:
## CI/CD
Pull Request作成時に、GitHub Actionsで以下を自動実行します。
- ESLint
- TypeScript typecheck
- Unit test
- Production build
次にローカルhookを入れる
次に、コミット前チェックを入れます。
最初はHusky + lint-stagedで問題ありません。
## Git hooks
Husky + lint-stagedを使い、commit前に変更ファイルだけformat/lintします。
この段階で、「CIまで待たずに手元でミスに気づける」状態になります。
その後にLefthookへ移行する
改善ストーリーとして強いのは、最初にHuskyで作り、その後Lefthookへ移行する流れです。
Before:
Husky + lint-staged
commit時にeslint/prettierを実行
After:
Lefthook
staged files対象
eslint/prettierを並列実行
READMEやPRには、なぜ移行したのかを書きます。
pre-commit hookの待ち時間が長く、commitのたびに開発テンポが落ちていたため、
Go製で起動が軽く、並列実行しやすいLefthookへ移行しました。
理由を書けることが重要です。
before/afterを数字で出す
改善は数字で見せると強いです。
## CI/CD改善
pre-commit hook:
- Before: 9.2s
- After: 3.8s
改善内容:
- Husky + lint-staged から Lefthook へ移行
- eslint / prettier を並列実行
- staged filesのみ対象化
GitHub Actionsも同じです。
GitHub Actions:
- Before: 7m 40s
- After: 4m 10s
改善内容:
- setup-node cacheを追加
- concurrencyで古いCIをキャンセル
- lint/test/buildをjob分割
数字は大きく盛らず、実測値を書きます。
PRを残す
ポートフォリオでは、改善PRを残すと見せやすいです。
PRタイトル例:
Improve pre-commit performance by migrating Husky to Lefthook
PR本文例:
## Summary
- Husky + lint-staged から Lefthook へ移行
- pre-commit hookをstaged files対象に変更
- eslint / prettierを並列実行
## Result
- Before: 約9秒
- After: 約4秒
## Why
コミット時の待ち時間を短縮し、開発テンポを上げるため。
このPR自体が説明資料になります。
面接で話すポイント
面接では、単に「CI/CDを入れました」より、次のように話すと強いです。
PR時にlint、typecheck、test、buildが走るようにしました。
最初は動けばよいと思っていましたが、CI待ちやcommit hookの待ち時間が開発速度に影響すると考え、
cache、concurrency、Lefthook移行で処理時間を短縮しました。
見られるポイント:
- 品質を自動化できる
- 開発体験を考えられる
- 計測して改善できる
- before/afterを説明できる
- チーム開発を想像できている
やりすぎには注意
ポートフォリオでCI/CDを盛りすぎる必要はありません。
避けたい例:
- 小さなアプリなのに複雑なワークフローが多すぎる
- 毎PRで重いE2Eを大量に回す
- 何のためのjobか説明できない
- CIの失敗を放置している
- READMEに実行時間や目的がない
シンプルで、理由が説明でき、実際に通っているCIが一番強いです。
READMEに書くテンプレート
## CI/CD
このリポジトリでは、開発品質と開発速度を両立するためにCI/CDを設定しています。
### Pull Request
- lint
- typecheck
- unit test
- production build
### Local hooks
- Lefthookでpre-commit hookを管理
- staged filesのみformat/lint
- eslintとprettierを並列実行
### 改善
- setup-node cacheで依存関係インストールを短縮
- concurrencyで古いCIをキャンセル
- HuskyからLefthookへ移行し、pre-commit時間を短縮
まとめ
ポートフォリオでは、CI/CD導入だけでも評価されます。さらに処理時間まで改善できると、実務を意識できていることが伝わります。
- まずPR CIを作る
- 次にpre-commit hookを入れる
- その後、HuskyからLefthookへ移行して速度を見る
- GitHub Actionsもcacheやconcurrencyで改善する
- before/afterをREADMEやPRに残す
- 面接で理由と効果を話せるようにする
「動くものを作った」から「開発し続けやすい仕組みまで作った」に見せ方を上げられます。
参考リソース
次に読む記事
← 一覧に戻るPR
PR
