>>299
お前はアホなのか。それも環境ごとにファイル用意して管理て話だから、.envコミット否定派のナレッジなんだが。後、まとめてくれてるやつってどれ？

>>300
前スレで「まとめ」で検索するといくつか出てくる
最後はこれかな？
http://medaka.5ch.net/test/read.cgi/php/1613209188/836

>>301
えｗ理解できてないの？
.envをコミットしなければならない環境で、どう管理するのが良いかってナレッジだぞ
コミットの否定なわけ無いでしょ

Q. Should I have multiple .env files?
A. No. We strongly recommend against having a "main" .env file and an "environment" .env file like .env.test.
Your config should vary between deploys, and you should not be sharing values between environments.

辞めたほうが良いよってdotenvの公式にも書かれてるけどね
どうしてもそうしたいなら好きにすればいいと思うけど、それはあなたのプロジェクト内の話であってデファクトみたいな顔すんのは違うんじゃねーの？

ミスってbe出ちゃった

ド直球のバッドノウハウをドヤ顔で「ナレッジ」と主張するのは草

>>304
デファクトの話は今してないよ
.envをコミットしなきゃならないプロジェクトに置かれたときに、前スレに有用そうな情報を提示してくれている人がいるってことと、世の中にはコミットしなきゃならないプロジェクトがあるってことを延々と説明させられてる

有用そうな情報を提供してくれている人がいるのに、それをまるっと否定するやつが邪魔なだけ

.envコミット否定派は、.envという.gitignoreされているものをわざわざコミット可能にするのは意味がないって言っているわけよ。理由は以下だ。
・環境ごとに異なるから
・クレデンシャル情報がコミットされるリスクがあるから

それに対して、.env.prdや.env.stgて別ファイルにして管理してますってのは.envコミット賛成派の意見なの？

.envをgitに入れてる事自体が一般的には異常なのにな
こういう奴らはsshのprivate keyとかも平気でgitに入れてそうで怖いわｗ

>>308
そりゃそうでしょ
そもそも各環境の.envをコミットする必要がなければ、、.env.prdや.env.stgて別ファイルにして管理する必要もない

>>308
賛成派っておかしくない？ここ一連の流れでは、「必要があるからコミットする」って説明しかしてないんだけど？

そんなわけあるか。事実、.env.exampleの存在を否定派は認めていたでしょ。否定してたのは.envてファイルそのもののコミットだよ。

>>312
君、やっぱり日本語の理解がおかしいぞ
ここまでのこのスレをもう一度読み直してみろよ
さっき提示したまとめレスでもいいけど

まとめを貼り付けておくね

・.envは環境を定義するためのものなので環境ごとに異なる。各環境に直置きし、ソース管理に含めないのがお手軽
・定義すべき内容（テンプレート）は.env.exampleで共有すると良い（こちらはソース管理に含む）

とはいっても.envを管理対象に含めたいプロジェクトはそこそこある
以下の対応をすると良い

＊機密情報の取り扱いに関して
厳密には、.envを管理する/しないとは関係がないが、以下のように整理すると良い
・どのような立場の人から情報を守りたいのかを定義し（セキュリティポリシー）、その対応としての実装を行う（ガイドライン）
・公式ドキュメントには、「source control repository」からの流出が一例として載っているが、その想定は一般的ではないのでポリシー設計時には自システムに対応した脅威を整理すること
・ルールで縛られることも多い。例えば「データベースへの接続情報は、ミドルウェアの管理者が管理する事」とか「特定管理者以外に資格情報は開示しない」とか
・実装方法は、.envに記述する/環境変数を使用する/変数として管理しデプロイ時に上書き等々あるが、ポリシーとセットで語られるべき内容なので省略

＊.envファイルの管理方法
以下のような実装方法がある模様
・環境ごとのファイルを用意して、環境変数APP_ENVで切り替える（注：defining a server-level APP_ENV）
・各環境のローカルリポジトリとして管理
・共通の.envを用意して部分的に環境変数で上書き
・共通の.envが使用できるように、デプロイ先の環境をそろえる

>>311
その必要なケースとは何？って聞いても
「客の依頼」とか「上司からの指示」しか答え返ってきてないけど
自身の主張は無いの？

「上司の指示でコミットするけど、自分はそれを合理的な指示だと思わない」
と
「上司の指示でコミットするし、自分もそれを合理的な指示だと思う」
の2パターンあるよね

前者の場合だと.envをコミットは否定されるから、結局客や上司の主張と合理性は関係ないよね。

おかしいのはお前だよ。老害認定する奴もそうだったけど、.env自体のコミットは意味ないって話だったのに、なんで、.env.stgや.env.prdが.envコミットすることと同義になるんだよ・・・。勝手にゴールポスト変更するなよ。

>>312
.env.exampleってただの設定例であって環境設定のそのものではない
.envや.env.stgなどは環境設定そのものであって持つ意味が全く異なる

>>312
いや馬鹿すぎでしょ
「環境設定の例」と「実際の環境設定」は異なることを理解してないのか君

この板で一番勢いあるスレになっちまったな

>>315
> 自身の主張は無いの？
それは、このスレで議論しても仕方ないって言ったはずだけど？
おおよそ不具合発生時の対応として発生したルールで、QCに関わる部分だから上意下達が普通
合理的かどうかは、開発部門全体が見れるポジションにいなければ判断できない
個社別の理由だからLaravelスレで開示されても困る

1中 composer.lock, package-lock.json をコミットしない
2右 vendor, node_modules をコミットする
3左 .envを別名で複数作る
4一 .envをコミットに入れる
5三 jsonをレスポンスするAPIは脆弱
6二 サロゲートキーをAIするのは頭が腐ってる
7遊 本番環境が開発環境
8捕 emailカラムにemailと関係無いユーザー識別子を入れる
9投 零細企業で勤務する

>>316
まとめみろよｗ
ゴールポスト動かしといて逆ギレするってｗww

>>321
これがこのスレにおける平均的ララベラーですね

>>321はさぞ優秀なんだろうなぁｗ
零細企業で勤務するとか大半が当てはまるやろ
てか大手に居る方がクソが多い気がするわ

>>318
同じだぞ。exampleはアプリケーションを開発環境で動かす際に必要な環境変数を定義しておく。もちろんクレデンシャル情報は除く。

.env.stgや.env.prdも同様。

違いがあるとすればそれを自動でロードするか手動で.env内にコピーして使うかの違いでしかない。

俺、今まで.envをコミットするのってネタだと思ってたんだけど、マジレス具合見てるとネタじゃなくて本気なんだと考えを改めるようになった

リファクタしました

1中 composer.lock をコミットしない
2右 vendor をコミットする
3左 .envを別名で複数作る
4一 .envをコミットする
5三 jsonをレスポンスするAPIは脆弱
6二 サロゲートキーをAIするのは頭が腐ってる
7遊 本番環境が開発環境
8捕 emailカラムにemailと関係無いユーザー識別子を入れる
9投 年収450万円上未満

>>326
.envをコミットしなきゃならん環境なんてでかい会社だと普通にある

「でかい会社」

>>328
なんでも記録取ろうとするからな
監督省庁がうるさい系だと小さい子会社てもコミットさせてそう

「でかい会社」ってのがどういう規模なのか知らんけど、
人数が多くなればなるほど機微情報をリポジトリに入れるリスクは増えるからありえないと思う、むしろ零細のほうがデメリットが少ない。
※ デメリットが減るというだけでメリットがあるわけではない。

>>330
記録が欲しいという観点だと開発用のリポジトリとは別の媒体で管理するけどね。
今俺が勤めてる会社はいわゆる中小企業だけど、親会社は大手でそこからの出向者も多く居る会社だけど、
本番や検証環境のクレデンシャルなんかは別の媒体で管理してて、閲覧可能なメンバーはデプロイ担当者とマネージャー系だけに限られてるよ。
リポジトリに機微情報入れるとか絶対にありえないよw

>>331
機微情報の取り扱い観点で論じるのはずれてる。まとめ読んでみ
セキュリティポリシー次第だけど、.envをコミットするしないとは関係ない

ミソとなるのは開発メンバー全員に本番環境のクレデンシャル晒すところだよね
確かに零細ならメンバー少ないしそこまで否定できないかも
大手ほどコミットするって話は本当に開発用リポジトリに対しての話なの？w

独立したリポジトリにコミットしてるとかなら話は別だしそれは否定することでも無いよ

>>333
まとめ読めｗ
なんで、クレデンシャルが.envに記述されてる前提なんだよ
それは別で検討すべきって書いてあるだろ

ナレッジとして使えるように整理しておいたわ。

論点1
クレデンシャル情報入りの.envをコードと同じリモートリポジトリで管理して良いか？

ありえない。理由は以下。
・プライベートであっても、リモートリポジトリは容易に設定ミスでパプリックになるリスクがあるから
・プライベートリポジトリはクラッカーの攻撃対象として常に脅威に晒されているから
・コードにアクセスできる人とクレデンシャル情報の人は基本的に一致しないから

管理上どうしても履歴管理したいなら、AWSなどが提供する専用サービスを使う、ローカルリポジトリまたは暗号化されたリモートリポジトリでコードと分けて管理するのが合理的。

履歴管理が不要なら、サーバー側の環境変数としてあらかじめ設定しておく。

論点2
クレデンシャル情報なしの.envをコードと同じリモートリポジトリで管理して良いか？

ありえない。なぜなら環境によって使用するパラメータが異なるから。

論点2-1
全環境同じパラメータを使う場合なら良いか？

ありだが間抜け。その場合はconfigファイルのデフォルト値に設定すれば良いので.env自体不要と考えるべき。

論点2-2
環境ごとのファイルを別途用意し、切り替えて使うなら良いか？

あり。

てか、年俸通知書を晒して一番高い奴が勝ちでよくね？

>>324
根拠一切無しの決めつけは草

>>335
論点1は個社のポリシー/ガイドライン設計で変わる。語りたいなら脅威分析した上で語れ
論点2は「なぜなら環境によって使用するパラメータが異なるから。」が確定なのか？
ほんと狭い視野だな

>>338
ゴミみたいなガイドラインでもそれに従えて話か？そんなエッジケース、論点でもなんでもないだろう。ナレッジって意味わかってるか？

>>338
そもそもdotenvは環境ごとに異なる値を吸収する為に作られてるライブラリなんだよ
その前提ガン無視かよw

環境ごとに異なるから.envに書いているのに、環境ごとに異なるとは限らないと主張するのは面白いな

>>341
安倍晋三かよw

>>340
しかも論点2-1にそれへのアンサーも書いてあるんだよね。

.envはもうどうでもいいよ
サロゲートキーで発狂する話のほうがまだ面白いわ

dotenvの解釈、足りてないぞ
設定をコードから分離する先としても機能する

>>339
そもそも組織のガイドラインなんだからエッジケースの話してんだけど、理解できてる？
組織のガイドラインとLaravelのガイドライン、組織内で使用するにはどっちが優先されるか自明だろ

>>346
ヤベーなお前。そんなエッジケースがここにいる他の奴らにどう役立つんだ？ナレッジの意味わかってるか？

>>340
dotenvの役割、半分しか理解できてないぞ
環境を記述するから差異も記述されるけどそれだけじゃない
環境設定をプログラミから外出しするための機能だって理解したほうがいい

>>347
だから言ってんじゃん
「.envをコミットしなきゃいけないプロジェクトに参加した人」の役に立つんだよ

>>344
これには同意

.envコミットの話は飽きたよ
だって何言っても「上司がー」「客がー」しか言わないんだもん