Github action戦略について

[ju-ki]

ブランチ

• master(デプロイ用)
• dev(統合テスト)
• feature(機能開発)
• fix(バグ修正)

基本方針(ブランチ)

• devから切って最終的にdevにマージし、適切なタイミングでmasterにマージ

基本方針(Github actions)

• TDDで作成する予定なので、feature or fixがプッシュされたタイミングでテストとフォーマッターを実行
• Github actionsをbackendとfrontend別々で行う(どちらで問題が発生したか分かりやすくするために)
• 両方通ればPRの作成(Github API)+Coderabbitによるレビュー(Open APIを使用もしくは手動)
• codeRabbitのレビューで問題があれば、ローカル修正+Github actions
• その際に大きな修正をしたら再度レビューしてもらう。(基本的には初回レビューのみ)
• devにマージする際は統合テストの実行(PR作成時)## ブランチ
• master(デプロイ用)
• dev(統合テスト)
• feature(機能開発)
• fix(バグ修正)

基本方針(ブランチ)

• devから切って最終的にdevにマージし、適切なタイミングでmasterにマージ

基本方針(Github actions)

• TDDで作成する予定なので、feature or fixがプッシュされたタイミングでテストとフォーマッターを実行
• Github actionsをbackendとfrontend別々で行う(どちらで問題が発生したか分かりやすくするために)
• 両方通ればPRの作成+Coderabbitによるレビュー
• codeRabbitのレビューで問題があれば、ローカル修正+Github actions
• その際に大きな修正をしたら再度レビューしてもらう。(基本的には初回レビューのみ)
• devにマージする際は統合テストの実行(PR作成時(手動))
• coderabbitによるレビューはなし
• 失敗した際はテストが通るまでマージができないようにする
• masterも同様で統合テストの実施+成功しないとマージができない
• masterにマージされたらNext.js(frontendディレクトリ)はvercel+laravel(backendディレクトリは)未定に自動デプロイを行えるようにしたいが、現時点ではまだ未定のため、ベースだけ作成し、実行はしない
• coderabbitによるレビューはなし
• 失敗した際はテストが通るまでマージができないようにする
• masterも同様で統合テストの実施+成功しないとマージができない
• masterにマージされたらNext.js(frontendディレクトリ)はvercel+laravel(backendディレクトリは)未定に自動デプロイを行えるようにしたいが、現時点ではまだ未定のため、ベースだけ作成し、実行はしない