サーバーとブランチの相関
ブランチ ＝ サーバー という関係性
ウェブ制作をする上でのベストプラクティスとして用意したいサーバーの種類は、
- ローカルサーバー
- プレビューサーバー
- ステージングサーバー
- プロダクションサーバー
の4種類です。
上から、製作工程に沿っています。
これらには、Git Flowの要素を関連付けて考えることが出来ます。
ローカルサーバー
ここでいう「ローカル」とは、みなさんの使っているPC内のことを指しています。
Git Flow では、ローカルリポジトリ（ブランチではなく）が関連付けられます。
ローカルリポジトリでチェックアウトしたブランチのソースコードは、すべてローカルサーバーで閲覧することになります。
Webpack Server、Docker、MAMP(XAMPP) などが、これに該当します。
チームメンバーすべてのPCで同じ環境を再現する
ということが、ローカルサーバーを構築する上での課題になります。
つまり、そのインフラ情報の共有に関しても、Gitで行うことが望ましいということです。
Webpackや、Dockerは、Gitを前提に設計されたツールであるため、おすすめです。
プレビューサーバー
ローカルサーバーを持たないメンバーを巻き込むとき、進捗を確認するために必要になるサーバーです。
また、ローカルサーバーを立ち上げずともコードレビューに使えるので、手回しが良くなります。
Git Flow では、リモートリポジトリにプッシュされた develop ブランチ や feature ブランチが、関連付けられます。
feature ブランチをプレビューサーバーに紐づけたい場合は、複数のプレビューサーバーがあると大変リッチです。
ブランチがサーバーに反映されるタイミング
リモートリポジトリのブランチ、つまりGitHub上でブランチに変更があった場合、そのソースコードがプレビューサーバーに反映されるようにします。
ブランチの変更とは、プッシュやコミットです。
ステージングサーバー
QA担当メンバーや、クライアントの最終チェックに使われるサーバーです。
Git Flow では、リモートリポジトリにプッシュされた release ブランチ、hotfix ブランチが、関連付けられます。
最大の特徴は、「そのまま本番になる」こと
ステージングサーバーの構成は、本番と全く同じにしなくてはいけません。
また、Git Flow の構成を厳守する必要があり、「ステージングサーバーの一部分だけ本番化する」というのもご法度です。
もし、一部分の機能だけを本番化したい場合は、release ブランチできちんと操作を加えるか、できれば develop まで工程を戻しましょう。
ということはつまり、release や develop の操作になるわけで、工数がかかるものだということを、営業担当も含め、共通認識として持ちましょう。
プロジェクトの進行を逆行させる行為なので、決して気軽に出来ることではありません。
これは、実は多くのトラブルの種になっているのですが、WEB制作現場では見過ごされている傾向にあります。
プロダクションサーバー
一般公開される、本番サーバーです。
いわずもがな、master ブランチが、関連付けられます。
大切なのは「独立させる」こと
プロダクションサーバーは、他のどのサーバーとも同じインフラを使ってはいけません。
一般公開されるとは、つまりあらゆる閲覧者に晒されるということであり、攻撃者（ハッカー）もそこに含まれます。
ステージングサーバーやプレビューサーバーが同じインフラに乗っていると、破壊行為に巻き込まれ、復旧活動が阻まれます。
また、攻撃でなくとも、コンテンツの成長に伴い、サーバーに負荷がかかることもあります。