はじめに
どうも。ビジネスサイド出身・非エンジニアPMのコーディです。
ここまで、AIを使わずに学習記録アプリを作ってみました。
正直、あの時点では「マジか動いた！」くらいのハイテンションでした。
でも、どこかでずっと引っかかっていたんです。
「ただ動かしただけで、本番運用できんし実務の全体像も見えないよな」
ということで今回は、
学習記録アプリを題材に
CRUD→テスト→CI/CD（自動テストとデプロイ）
を全部つなぎにいったので書き残します。
なぜ CI/CD までやろうと思ったのか
ちょっと勉強するノリの個人開発って、正直「動いた！できた！」で止まりがちですよね。
- 画面が動く
- データが保存できる
- ちょっとUIも整えた
で、満足して終わる。
ただ、PMとしてプロダクト開発に関わっている身として、
それでいいのか？という違和感がありました。
- pushしたら何が起きるのか
- どこで壊れるのか
- 何をもって「本番に出せる」「実践の場で戦える」と言えるのか
CI/CDを知らないPMは、「本番」を想像できていない。
自分がまさにそれだと思って、ちゃんと一度、自分の手で通してみることにしました。
作ったもの（おさらい）
作ったのは、前回と同じ学習記録アプリです。そのまま流用してます。
機能はかなりシンプル。
- 学習内容と学習時間を登録
- 登録した履歴を一覧表示
- 学習記録の削除
- 合計学習時間の表示
技術スタックは以下。
- フロントエンド：React + Vite
- DB：Supabase
- Hosting：Firebase
- CI/CD：GitHub Actions
今回は「機能を増やす」よりも、
開発の流れを最後までつなぐことをテーマに。
CI/CD を「つなぐ」という作業が、想像以上に重かった
GitHub Actions でやりたかったことは、かなりシンプルです。
- npm test
- 通ったら npm build
- Firebase に deploy
ただ、実際にやってみると、
この「当たり前」が一気に重くなりました。
軽く不正解な実装で実験してみて、
- テストが1つ落ちたら、即デプロイ不可
- 環境変数がズレていたら、全部止まる
- ローカルで動いても、本番では関係ない
「動くコード」と「通るコード」は、全然別物だと実感。
ただ、pushした瞬間に、テスト → ビルド → デプロイ
が自動で走るのを見て、
「あ、いつもプロダクトで見てるやつだ。やっと自分の手で本番の領域に足を踏み入れた」
と、ちょっと感動もしました。
テストがあるから、CI/CD が意味を持つ
正直に言うと、テスト単体で見たときはイヤになった。しんどい。
Vite × Jest の相性問題で数時間溶かしたり、
mockや設定で意味不明になったり。
そのあたりは、前回の記事に全部書いています。
ただ、CI/CD とつながった瞬間、
テストが通らない＝本番に出ない
テストが通る＝最低限の安心がある
テストは品質保証じゃなくて、「自分を信用するための装置」 だと思えました。
テスト感謝。うちのプロダクトもちゃんとリリースされたし、E2EでTDDやっていきたいものです。
正直、めちゃくちゃしんどかった
ここは綺麗事なしで書きます。
- テスト書くのダルすぎ
- ログを見ても何が原因か特定するの大変
- 「昨日動いたのに今日動かない」がよくある
- ちょっとミスったら被害が甚大
何度も「もうダルい。イヤや。」状態になりました。
でもこれ、チーム開発では当たり前に誰かが向き合っている世界なんですよね。
PMとして、エンジニアの皆さんにもっと寄り添って支えられるように、楽しんでもらえるように頑張ろうと思いました。
おわりに
初めての個人開発としては、正直かなり大変でした。
何度も詰まったし、分からないことだらけでした。
でも、CRUD→テストCI/CD が一本の線でつながった体験は、想像以上に大きかった。いい学び。
まだまだ弱いですが、世界的な企業を目指す開発部統括・PMとして、さらにレベルを上げ続けていきます。