プルリクエストのレビュー（テスト）方法

Question

複数の機能追加を並行して行うため、
開発後に、プルリクエストを送信してもらい、
コードレビュー後に、マージおよびリリースする手順を取っています。

ここで、コードレビュー時（マージ前）に、
プルリクエストが反映されたコードを、開発環境にリリースする方法はありませんでしょうか？

一度、マージしてからだと、該当のプルリクエストにバグが含まれていた場合に
他のプルリクエストから先にリリースするといった事がしにくくなると考えているため、
マージする前に、一度サーバ（開発環境）で動かしてみたいと思っています。

文字ばかりで分かりにくい説明でしたら申し訳ございません。
ご遠慮なく質問、またはアドバイスをいただけますと幸いです。

よろしくお願い申し上げます。

Answer 1

私だったら、修正が入ってる方のブランチ(以下、開発ブランチ)で
$ git rebase origin/master
もしくは
$ git merge origin/master
等を実行し、最新のmasterを開発ブランチに取り込んでから、開発ブランチのソースを開発環境へ手動でリリースします。
プルリクエスト作成時などに自動でリリースしたい場合は何かCDツールを導入することになると思いますが、複数人で開発している場合、うっかり他の人がテストしている環境を上書きしてしまうリスクがあるので、このケースでは個人的にはオススメしません。

Answer 2

ちょっと抽象的すぎてよくわかんないですけど、モダンな感じだとPRが出ると自動でDockerコンテナ内で一通りテストされてPRにOKコメントが付くっていうCIが多いですね。

Gitflowだと、
featureブランチにdevelopをマージして、PRを出して、テストが通ればdevelop側にマージして良し。ってかんじです。

テストとかなくて、泥臭く行く覚悟があるなら、本番環境に似せたコンテナイメージを作っておいて都度都度デプロイしながら動作を確かめるというのもいいかも。オススメはしないけど。