gitでのバージョン管理＆デプロイ環境構築について

Question

前提

gitを使用しWebサイトのバージョン管理＆デプロイ環境を作ろうとしています。

・本番環境　…　一般ユーザに公開。
・ステージング環境　…　クライアントに公開。本番環境＋未リリースの内容を含む。表示の崩れ等はNG。
・開発環境　…　社内のみ。作業途中などで表示が崩れてもOK。

の3つのサーバーを用意し、それぞれ master・staging・develop のブランチを割り当てる予定です。
リモートリポジトリにはBacklogを使用します。

以下、質問事項になります。

質問事項

【1】環境依存の設定ファイルについて

各環境で共通のファイルをgitで管理することは用意に想像できるのですが、
環境依存のファイル、例えば

・本番とステージングでincludeのパスが違うファイル
・メール送受信のアドレスが違うファイル
・データベースの設定ファイル
・本番環境のみにしか存在しないファイル

などの管理はどうするのがセオリーなのでしょうか。
これらはバージョン管理に含めないという選択肢は、大きな問題になり得るでしょうか。

【2】作業フローについて

サイトを更新する場合、

1. 'master' から 'feature/○○○○' ブランチを切る
2. 作業完了後、社内確認のため 'develop' にmergeしてpush（開発環境へデプロイ）
3. 社内確認後、'staging' に 'feature/○○○○' をmergeしてpush（ステージング環境へデプロイ）
4. クライアント確認後、'master' に 'staging' をmergeしてpush（本番環境へデプロイ）

という作業フローを考えています。

軽微な変更（一部のテキスト変更など）は、

1. 〃
2. 作業後 'staging' にmergeしてpush
3. 'master' にmergeしてpush

とする予定です。
上記フローで、何か起こりうる問題点等ございますでしょうか。

【3】一部機能のみを反映させたい場合

ステージング環境に「本番環境＋機能A＋機能B」がアップされているとします。
このうち機能Aのみを本番環境へアップする場合、具体的にどういった手順を踏めばよろしいのでしょうか。

補足情報

社内にはバージョン管理の文化が全く無く、
本番環境のファイルを直接編集したり、サーバー上にリネームしたファイルをバックアップとして置いておくようなレベル感です。
私自身、gitは自分の更新履歴程度にしか使っておらず、今回、初めて運用としての利用を試みております。
極々初歩的な質問かもしれませんが、何卒よろしくお願い致します。

Answer 1

今時はどのフレームワークでも.envの仕組みがあるのでは。
Push to Deployの前にフレームワークとか調べて世間一般で当たり前に行われてることを知っておかないと
.envと同じものを自分で作るような無駄な作業することになる。

Comments

[ukotsu]

ご回答有り難うございます。
サーバーサイドにはphpを使っておりますが、一般的なフレームワークは使用しておりません（社内のフレームワークです）
.envのような仕組みがあるかを確認致します。

Answer 2

全体的に「正解」は無いと思いますので「自分だったらこうする」という回答になりますが、ご容赦ください。

【1】環境依存の設定ファイルについて
サーバーごとに環境変数を設定するのはいかがでしょうか？
環境変数を読み込むようなソースの書き方をすれば、ソース自体は同じもので大丈夫なはずです。

【2】作業フローについて

1. 社内確認後、'staging' に 'feature/○○○○' をmergeしてpush（ステージング環境へデプロイ）

この箇所は
社内確認後、'staging' に** 'develop'** をmergeしてpush（ステージング環境へデプロイ）
が良いように感じます。

軽微な修正に関しては書かれている流れで問題ないかと思います。

【3】一部機能のみを反映させたい場合
ステージング環境は基本的に本番とほぼ同じ状態にしておくべきですので、ステージング環境の方を「本番環境＋機能A」という状態に戻す（developブランチが「本番環境＋機能A＋機能B」という状態）が正しいフローかと思います。

Comments

[ukotsu]

ご回答ありがとうございます。
仰る通り、絶対的な正解は無いと思いますので事例や知見をお教えいただけますと幸いです。

【1】環境依存の設定ファイルについて
>サーバーごとに環境変数を設定するのはいかがでしょうか？
>環境変数を読み込むようなソースの書き方をすれば、ソース自体は同じもので大丈夫なはずです。
各サーバーにそれぞれ設定ファイルを設置する、ということでしょうか。
ということは、その設定ファイル自体はgitの監視に含めない（＝バージョン管理をしない）という認識でよろしいでしょうか。

【2】作業フローについて
'develop（開発環境）' は複数の人間が複数の機能を社内確認用にアップしているので、必ずしも全てがstagingにmergeできる状態ではありません。
この場合でもdevelopからstagingへmergeするほうがベターでしょうか。（チェリーピック等を使って？）

【3】一部機能のみを反映させたい場合
>ステージング環境は基本的に本番とほぼ同じ状態にしておくべきですので、ステージング環境の方を「本番環境＋機能A」という状態に戻す（developブランチが「本番環境＋機能A＋機能B」という状態）が正しいフローかと思います。
なるほど。
1. ステージングを「本番環境＋機能A」の状態にする
2. 本番環境へmerge
3. ステージングを「本番環境＋機能B」の状態にする
というフローを踏むということで合っていますでしょうか？

[Takuya_Ando]

【1】環境依存の設定ファイルについて
>各サーバーにそれぞれ設定ファイルを設置
そうですね。その認識で良いかと思います。
こちらのページがわかりやすいです。
https://blog.excite.co.jp/exdev/27192382/

>設定ファイル自体はgitの監視に含めない
こちらもその認識ですね。
.envを.gitignoreに追加してgitの監視に含めないという流れです。

【2】作業フローについて
>必ずしも全てがstagingにmergeできる状態ではありません。
その場合であれば直接の方が良いかもしれないですね。

【3】一部機能のみを反映させたい場合
はい、その認識です。

[ukotsu]

再度のご回答ありがとうございます。

【1】環境依存の設定ファイルについて
.envについて調べていたところ、ちょうどお教え頂いた記事を読んでおりました。
導入を検討しようと思います。

【2】作業フローについて
ご検討ありがとうございます。一旦そのフローで運用をしてみようと思います。

【3】一部機能のみを反映させたい場合
ありがとうございます。
こちらもそのフローで運用を致します。