Laravel REST APIとReactフロントエンドのデプロイがここまで大変だとは思っていなかった。開発自体は難しい部分ではなかった。私のLaravelの語彙は改善の余地があるが、それが本当に重要になるのは、そのスタックを使うプロジェクトや仕事に就いたときだけだ。しかしデプロイでは、物事が崩れ落ちた。
何がうまくいかなかったか
短く言えば、マイグレーション、シーダー、パーミッションエラーが私の人生の2時間を食い尽くした。
私はホームラボで共有PostgreSQLインスタンスを運用している(Redisも同様)ので、プロジェクトごとに別々のリソースを立ち上げることはしない。つまり、このアプリのために、私は手動で新しいデータベースを作成し、バックエンドの.envが実際に接続してマイグレーションを正しく実行できるように、テーブルの所有権を変更しなければならなかった。動きはするが、洗練されているとは言えない。
振り返ってみると、手作業でやる代わりに、データベースとユーザーのセットアップを処理するための適切な.shスクリプトを書いておくべきだったと思う。今回はもう遅いが、次回のためにツールボックスに入れておく。
Fakerの問題
もう一つの大きな時間の浪費: シーダーでFakerを使っていたのだが、それはrequireではなくrequire-devに置かれていた。つまり、本番環境でシーダーを実行しようとするたびに失敗していたということだ。それに気づいて正しい場所に移動するまで、2回のリビルドを要した。
まとめ
- 共有PostgresとRedisインスタンスはリソースを節約するが、デプロイ当日まで忘れがちな手動セットアップステップ(DB作成、所有権変更)を追加することになる。
- 新しいデータベースとユーザーをプロビジョニングするための再利用可能な
.shスクリプトがあれば、あの2時間のかなりの部分を節約できていただろう。 - 実際に本番環境に送る必要のある依存関係を再確認すること。Faker、そしてシーディングやテストのためだけに使われる他のものは、本番フローで決して必要にならない場合のみ
require-devに属する。もし必要になるなら、上に移すこと。
デプロイ当日は、いつも開発当日に見逃されたギャップを見つけ出す。今回はいつもより多く見つかっただけだ。