環境間で構成ファイルを管理する
あなた（あなたの会社）はあなたが構築したアプリ/システムの設定ファイルをどのように管理していますか？私たちがそれをどのように行うか、そして問題は何であるかをお話ししましょう。
私は約15人の開発者とソフトウェアを開発している会社で働いています。マネージドホスティングプロバイダーにデプロイされる基幹業務Webアプリを構築します。メインアプリの1つは、1つのWebサイトと約10のWCFサービスで構成されています。一部のサービスは相互に接続されています。
これが大きなシステムなのか小さなシステムなのかはわかりませんが、さまざまな環境（テスト、受け入れ、本番）で稼働させるには時間がかかりすぎると思います。
Visual Studioプロジェクトには、環境ごとに構成ファイルがあります。したがって、web.test.config、web.acc.config、web.prod.configとweb.config開発用。それらはすべて同じキーを持っていますが、それらが意図されている環境に応じて、値が異なる場合があります。
Webappのweb.configでアプリ設定をすばやくカウントすると、32がカウントされます。5つのエンドポイントがカウントされます。 4つの環境（dev、test、acc、prod）があります。これは、1つのWebアプリに対して合計128のアプリ設定と20のエンドポイントを意味します。特に締め切りが迫っているときは、簡単に間違いを犯す可能性があります。
私たちは皆人間なので、このようなことが誰にでも起こる可能性があります。
- 構成ファイルの1つに変更を加えましたが、ビルドしてデプロイする前にチェックインするのを忘れています。
- または、Webサーバーに変更を加え、他の4つのweb.configでそれに応じて更新するのを忘れます。
- または、4つの構成ファイルのうち3つだけを変更します。等々。
次に、マネージドホスティングプロバイダーにインフラストラクチャがあります。デフォルトでは、すべてのポートが閉じられています。したがって、WCFサービスの1つが別のサーバーにある他のWCFサービスと通信する必要がある場合は、ファイアウォールで保護されたポートを開く必要があります。
これはテストで行いますが、アクセプタンスではもう一度行う必要があり、どのポートを開く必要があるかを忘れているため、試行錯誤のようなものです。ああ、私のサービスはデータベースに接続できません。おそらく、ポートが閉じています。同じ問題が本番環境でも発生する可能性があります。
SLAによると、マネージドホスティングプロバイダーはファイアウォールでポートを開くのに数日かかる場合があります。したがって、これはすぐにかなり長いプロセスになります。そして最終的には、テスト、受け入れ、本番環境が稼働するまでに約2か月かかります。
ですから、私の質問は、構成とインフラストラクチャ、およびその周辺のプロセスをどのように管理するかということです。
Config4 * プロジェクト（免責事項：私はその主要な開発者です）には、.NetまたはWCFとのすぐに使用できる統合がないため、おそらく役に立たないでしょう。ただし、Config4 *の機能の1つは、質問に関連しています。これは、構成ファイルにif-then-elseステートメントを埋め込んで、ファイルがさまざまな環境（開発、テストなど）に「適応」できるようにする機能です。 、受け入れと生産）。
.Net/WCFベースのプロジェクトで使用している構成構文で機能するようにその概念を変更できる場合があります（これらのテクノロジには精通していませんが、おそらくXMLベースの構成ファイルを使用していると思います） 。特に、たとえばPythonを使用して、if-then-elseステートメントを使用して環境固有のname = valueペアを設定するスクリプトを作成できます。 map、次にいくつかのprintステートメントを使用して、環境に合わせた構成ファイルのセットを生成します。このようなスクリプトの擬似コードの概要は次のとおりです。
#--------
# Set up configuration variables suitable for a specified environment
#--------
cfg["variable1"] = "default value";
cfg["variable2"] = "another default value";
if (environment == "testing") {
cfg["variable1"] = "override default value for this environment";
cfg["variable3"] = "value suitable for this environment";
...
} else if (environment == "production") {
...
}
#--------
# Now use print statements to generate configuration files
# Alternatively, use the _name=value_ pairs in the map to
# perform global search-and-replace on template versions of
# configuration files.
#--------
...
ボーナスポイントとして、スクリプトは、環境に対して実行する必要のあるテストのチェックリストを生成することもできます。たとえば、「次のエンドポイント間でファイアウォールポートを開く必要があるかどうかを確認してください：...」。
私たちは分散ストレージシステムを開発しており、すべてのビルドで実行されるユニットテストと統合テストでこのような多くの問題を見つけています。また、他の開発者がコミットする前に変更を確認できるように、ReviewBoardを使用しています。次のステップは、さまざまな環境でアーティファクトを自動デプロイしてテストする継続的インテグレーションサーバー（jenkins）です。最後に、私たちの最後の防衛線は、公開される前に、新しいバージョンに対して実行されるストレステストテストベッドです。もちろん、本番環境を可能な限り模倣するテストベッドを用意することは不可欠ですが、常に同じホスティングプロバイダーにデプロイする場合は、それほど難しくはありません。
あるファイルの変更が他のファイルで忘れられているなどの特殊なケースについて：テストスクリプトで自動チェックするのは非常に簡単だと思います。
コミットされていない変更は、「gitdiffmaster」や使用するvcsと同じくらい簡単に検出できるはずです。
サービスのためにどのポートを開く必要があるかを知ることは、構成管理よりも適切なドキュメントの問題のようです。
私たちのシステムを使用するサイトの多くは、さまざまなノードの構成を管理するためにpuppetも使用しています。それがあなたの選択肢になるかどうかはわかりませんが、一見の価値があるかもしれません。
これは役立つかもしれません、それは1つのソースから参照する設定ファイルとサービスのための中央の場所について話します。
Ansibleテンプレート または SaltStack を使用して、すべての構成ファイルを簡単に管理できる十分に小さい環境があるようです。
http://www.configapp.com でConfigを見てください。それが機能する方法は、web.configと呼ばれる基本構成ファイルをインポートすることです。次に、webapp内から、dev、test、acc、prodの4つの環境を作成します。開発環境に移動し、環境変数を作成して、環境に適した値を設定します。環境変数を含む構成ファイルを1つだけ維持します。すべての環境変数を確認でき、環境間の違いを簡単に確認できます。
管理する構成ファイルが1つしかないため、ミスが少なくなります。新しい共通/静的構成を追加すると、すべての環境が魔法のようにその新しい設定になります。変数構成を追加するときは、正しい環境タブに移動して、そこに値を設定するだけです。すべての環境の特定の構成値を表示できるため、何かを見逃していないかどうかをすばやく確認できます。また、環境ごとに各構成ファイルを目で確認することもできます。これらはすべて目の前にあるからです。各サーバーにRDP/SSHを実行する必要はありません。
Configがマスターコピーになるため、チェックインすることを忘れないでください。また、構成ファイルを直接編集することはもうありません。それらを直接編集する場合は、マスターとローカルコピーの違いを確認できるように差分機能があります。チームに適したさまざまな展開モデルを使用して、マスターコピーをローカルサーバーに展開できます。プッシュ、手動プル、自動プル、またはエクスポート/コピーが可能です。
カスタムタイプをサポートします。将来追加できるのは、ポートデータタイプです。ポート検証の一部は、ポートが開いているかどうかをチェックすることです。これは、内部ネットワークにアクセスする必要があるため、オンプレミスプランを使用した場合にのみ機能します。または、手動で確認することもできます。ポート環境変数に移動し、現在構成されているすべてのポートを表示します。リストの各ポートを確認してください。ポートに問題がない場合は、Configにコメントを追加して、ポートが開いていて、特定の日にチェックされたことを確認します。 Configは、検索と文書化のために設計されています。
ちなみに、私はConfigチームの一員です。
個人的には、可能であれば、次のように管理します。すべての「静的」環境設定（データベース接続、LDAPなど）はサーバー構成ファイルに配置され（コード移行の影響を受けません）、「動的」設定はデータベース自体。
したがって、設定の更新はデータベースチームにのみ依存しています（データベースに直接アクセスできる場合は、より簡単です）。また、開発用PCでprodデータベースを指すコードを実行するリスクはありません：D
しかし、私はVisual Studioの経験がないので、あなたのケースに同様の何かを適用できるかどうかはわかりませんが、それがあなたにいくつかのアイデアを与えることを願っています。
展開管理ツールを使用して処理することを検討しましたか？約10種類のシステムが相互に通信する必要のある製品を展開するために運用チームと協力してきましたので、あなたの状況を本当に理解しています。ソリューション全体の展開には、約4時間の手動手順と2時間のテストが必要でした。 Octopus Deploy（ https://octopus.com ）を使用して、デプロイメントプロセスを自動化することにしました。このツールは、構成ファイルで変数の置換を行うことができ、環境ごとに変数を定義できます（その他...）ソリューション全体の展開が約15分で起動し、最終結果は常に良好です...リリースをトリガーすることもできます作成と展開はTFS、VSTS、Jenkins、またはTeamCityから直接行われるため、非常に堅固なCI/CDアプローチを採用できます。
お役に立てれば。