Gitの慣習
変更履歴を自動的に生成するコンベンショナルコミット（feat:、fix:、chore:）を使用します。ブランチはチケットにちなんで命名されます：feat/ZENO-123-add-heatmaps。
コミットメッセージは命令形（「ヒートマップを追加する」ではなく「ヒートマップを追加しました」ではなく）で、何をしたかではなく、なぜしたかを説明すべきです。差分は何が変わったかを示します—メッセージは理由を説明すべきです。
プルリクエスト
すべての変更はコードレビューを経ます。PRは小さく、集中していて、レビュアーへのコンテキストを含むべきです。営業時間中は4時間以内のレビューを目指します。
PRの要件：
- すべてのテストが合格
- 型チェックの成功
- 少なくとも1つの承認
- 未解決のコメントなし
良いPRの説明には：何が変わったか、なぜ変わったか、テスト方法、リスクや後続作業が含まれます。
CI/CDパイプライン
すべてのプッシュでCIパイプラインがトリガーされます：リント、型チェック、テスト、ビルド。mainへのマージで自動的にステージングにデプロイされます。本番デプロイには明示的な承認が必要です。
パイプラインは5分未満で実行されます。それ以上かかる場合は修正すべきバグとして扱います。速いフィードバックループがデベロッパーの生産性を維持します。
環境管理
3つの環境を維持しています：
- 開発： WorkersにはWrangler、Supabaseにはローカルインスタンスを使ったローカルマシン。
- ステージング： ステージングサブドメインの本番ライク環境。最終的なQAとデモに使用。
- 本番： 本物です。ステージングの確認と明示的な承認後にデプロイ。
データベースマイグレーション
スキーマ変更はSupabaseのマイグレーションを経ます。すべてのマイグレーションは対応するダウンマイグレーションで元に戻せる必要があります。本番に適用する前に、本番ライクなデータでステージングのマイグレーションをテストします。
リリースプロセス
継続的にリリースします。機能はフィーチャーフラグで保護されながら、準備ができ次第公開されます。主要な変更は明確な移行ガイドとともに変更履歴で発表されます。
フィーチャーフラグにより、ユーザーに対して有効にせずにコードをデプロイできます。これにより、より安全なリリース、段階的なロールアウト、問題が発生した場合の簡単なロールバックが可能になります。