ローカル開発で環境変数を管理する方法
私は開発者の小さなグループ（具体的には6.5人の開発者）向けの開発哲学ドキュメントを書いている最中ですが、理想的には、チームの規模が拡大するにつれ、会社のベストプラクティスが明らかになるドキュメントです。このドキュメントを作成する過程で、私は各エンジニアにインタビューして、開発プロセスを理解し、冗長な作業を排除するのに役立つ、そして過度に規定的ではないものをうまく組み合わせるためのものを作りました。
私が見つけたほとんどの問題にはかなり良い解決策がありますが、良い解決策を見つけることができないように思えない一般的な問題であるに違いないと私は思います。これは、ローカル開発に必要な環境変数の管理です。たとえば、AWSの開発キーがあります。開発中のアプリケーション内で多くの機能を使用する必要があります。
現在、プロセスはかなり悪いです。明らかに、組織全体にアクセスさせたくない機密情報であるため、envファイルをGithubにコミットすることはできません。現在、開発に必要なenvファイルを含む安全なS3ファイルがあります。
新しい環境変数をこのファイルに組み込むこと、および開発中にこれを引き下げることの両方に関して、これを最新の状態に保つことには多くの問題があることがわかりました。これは、Githubの一部ではない開発サイクルの単一の部分であるため、それほど驚くことではなく、更新またはアクセスがほとんど必要ないものです。とはいえ、人々が問題に遭遇したとき、間違ったS3キーを持っている、または何かが標準的な種類のエラーチェックではないことに気づくので、それは非常にイライラすることがあります。
人々が特にうまく機能していることがわかっている環境変数を管理するためのソリューションはありますか？従業員に、現在入手できる最高のソリューションであるレポを作成してもらいました（ https://github.com/sihrc/privvy ）が、もっと良いものはありますか？
編集：プライベートリポジトリがこの問題の解決策ではない理由（私たちはすでにプライベートリポジトリを使用しています）
これらの変数は、単一のプロジェクトに限定されません。たとえば、開発環境ファイルは
このファイルをバージョン管理すると、開発が困難または不可能になります。 APIキーをロールする場合、それは私たちが永遠に使用する必要があるAPIキーです。古いリビジョンと主要な変更に戻す必要がある場合、それは問題です
リポジトリにサードパーティを追加する必要があるのは不思議ではありません。資格情報ではなくコードを表示できることが非常に重要です。
組織全体がアクセスできないようにする機密情報であるため、envファイルをGithubにコミットすることはできません。
情報が機密であるという事実は、それがバージョン管理下に置かれるべきではないという意味ではありません。同様に、GitHubを使用しているからといって、すべての情報が公開されているとは限りません。 GitHub Enterpriseにはプライベートリポジトリがあり、社内では個々のリポジトリを従業員のサブセットに制限できます。
現在、開発に必要なenvファイルを含む安全なS3ファイルがあります。
それは正しいアプローチではありません。構成を1つの場所（バージョン管理）に置く代わりに、情報を2つの異なる場所に配置します。 S3はバージョン管理をサポートしていますが、Gitほど簡単ではありません。最後に、企業のSSOサーバーを使用するようにS3を何らかの方法で構成していない限り、S3ファイルにアクセスする必要があるすべてのユーザーに対して追加のアカウントを作成する必要があります。これは、深刻なセキュリティ問題への扉が開かれています（「S3ファイルにアクセスできません。アカウントに再び問題があるようです！」、「まあ、私のものを使用してください。パスワードは...のようなものです）。
新しいenv変数をこのファイルに組み込むことと、開発中にこれを引き下げることの両方に関して、これを最新に保つことと、両方に多くの問題があることがわかりました。
明らかに。以下で説明するように、2つの原因により複雑さが増しています。
人々が特にうまく機能していることがわかっている環境変数を管理するための解決策はありますか？
プライベートリポジトリ。
私がいくつかの会社で見た別の解決策は、設定を公開リポジトリに公開することですが、それを暗号化することです。このアプローチの問題は、多くの場合、暗号化キーをどこかに格納し、さらに重要なことに共有する必要があるという事実です。これにより2つの問題が発生します。
不満を持つ従業員があなたの鍵を持っている場合、あなたはすべてを新しい鍵で解読して再暗号化し、すべての関係者に新しい鍵を共有する必要があります。
誰もが同じ鍵を共有します。小規模なチームでは問題ないかもしれませんが（これが推奨されるアプローチである理由はわかりません）、キーを部外者（コンサルタント、インターン、または他の人）と共有する必要がある場合はすぐに問題になりますチーム。
さらに、このファイルのバージョン管理は必要ありません。このファイルのコミットまたは差分は意味がありません
不満を持つ従業員が初めてS3ファイルをめちゃくちゃにすると、すべての変更の永続的な履歴を持つことが不可欠であることがわかります。
差分についても同じです。誰かが間違ったキーを取り違えたことを理解し、適切なキーを取り戻す方法を見つけるのに何時間も費やすことは、すべての変更を段階的に追跡できるので、あまり面白くありません。
プライベートリポジトリがこの問題の解決策ではない理由（私たちはすでにプライベートリポジトリを使用しています）
- これらの変数は、単一のプロジェクトに限定されません。たとえば、開発環境ファイルは
GitHub Enterpriseにはブランチ制限機能があります。ディレクトリごとのアクセスほどきめ細かいわけではありませんが、機能する場合があります。
それ以外の場合は、GitHubからサービスに切り替えて、ディレクトリごとのアクセスを制限することができます。個人的には、私が展開するすべての仮想マシンの構成を含むSVNリポジトリを使用しています。1つは公開されていますが、もう1つはAmazon AWS、Google、Twilioへの秘密鍵などの機密データが含まれていますサービスは、指名された人に制限されています。単純なディレクトリで構成されています。
- このファイルをバージョン管理すると、開発が困難または不可能になります。 APIキーをロールする場合、それは私たちが永遠に使用する必要があるAPIキーです。古いリビジョンと主要な変更に戻す必要がある場合、それは問題です
すべてのケースで機能する実際の解決策があるとは思いません。たとえば、2日前に行った変更がBing MapsからGoogle Mapsに移行された場合はどうなりますか？その間、すべてのBing Maps APIキーを削除した可能性があります。したがって、誰かが古いバージョンに戻った場合、それは機能せず、あなたにできることは何もありません。
それ以外の場合、APIキーの変更に関しては、これは非常にまれです。セキュリティ違反がない限り、これらのキーを定期的に変更する意味はほとんどありません。
- リポジトリにサードパーティを追加する必要があるのは不思議ではありません。資格情報ではなくコードを表示できることが非常に重要です。
こっちも一緒。 GitHub Enterpriseのブランチ制限、またはこの機能をサポートするバージョン管理システムのディレクトリごとの権限。