跨環境管理配置文件

Question

您（貴公司）如何管理您構建的應用程序/系統的配置文件？讓我告訴你我們如何去做，問題是什麼。

我正在一家公司工作，我們在那裏與大約15名開發人員一起開發軟件。我們構建部署在託管託管服務提供商處的業務線Web應用程序。 我們的一個主要應用程序由一個網站和約10個WCF服務組成。一些服務相互連接。

我不知道這是一個大系統還是小系統，但我認爲需要我們太長時間才能在我們的不同環境（測試，驗收和生產）中運行並運行。

我們在Visual Studio項目中的每個環境都有配置文件。因此開發了web.test.config，web.acc.config，web.prod.config和web.config。它們都具有相同的密鑰，但其值可能不同，具體取決於它們的環境。

如果我對Web應用的web.config中的appsettings進行了快速計數，我計數爲32.我計算了5個端點。我們有四種環境（dev，test，acc和prod），這意味着一個web應用程序共有128個appsettings和20個端點。我們可以很容易地犯錯誤，尤其是在截止日期截止時。我們都是人，所以每個人都會遇到這種情況：我們在配置文件中進行更改，但在構建和部署之前忘記檢查。或者我們在網絡服務器上進行更改，並忘記在四個web.configs中更改它。或者我們只更改四個配置文件中的三個。等等。 然後我們在託管託管提供商處擁有基礎架構。默認情況下，每個端口都關閉。因此，如果一個WCF服務需要與另一個服務器上的另一個WCF服務進行通信，則必須在防火牆中打開一個端口。我們在測試中這樣做，但在接受中我們必須再次執行此操作，並且我們已經忘記了哪些端口必須打開，所以更像是反覆試驗：噢，我的服務無法連接到數據庫，可能是港口已關閉。同樣的東西再次發生在生產中。據SLA稱，我們託管的託管服務提供商可能需要幾天才能在防火牆中打開一個端口。所以，這很快就會變成一個相當漫長的過程。最後，我們需要花費大約兩個月的時間才能完成測試，驗收和生產。

所以，我的問題是：你如何管理的配置，基礎設施和周圍的過程嗎？

Answer 1

這可能有所幫助，它討論了從一個來源引用配置文件和服務的中心位置。

http://blogs.msdn.com/b/youssefm/archive/2010/09/02/loading-wcf-client-configuration-from-different-files-with-configurationchannelfactory.aspx

Answer 2

的Config4*項目（免責聲明：我是它的主要開發者）沒有與.NET或WCF一個徹頭徹尾的現成的集成，所以它可能不是對你有用。然而，在CONFIG4 *的特徵之一是有關您的問題：它是嵌入在配置文件中的if-then-else語句，以便該文件可以針對不同的環境（如開發，測試「適應」本身的能力，驗收和生產）。

您可能會修改該概念以使用您在基於.Net/WCF的項目中使用的任何配置語法（我對這些技術並不熟悉，但我猜測他們可能使用基於XML的項目）基於配置文件）。特別是，你可以用，比如，Python中編寫一個腳本，使用的if-then-else語句來設置特定的環境名稱=值雙在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. 
#-------- 
... 

獎勵積分，腳本也可以產生需要的環境下進行，例如測試清單「，檢查是否有防火牆端口需求以下端點之間被打開...」

Answer 3

個人而言，如果可能的話，我管理它通過以下方式：所有‘靜態’環境設置（數據庫連接，LDAP等）放置在服務器配置文件（不受代碼遷移影響）以及數據庫本身的「動態」設置。

所以，我只能依靠數據庫團隊更新設置（如果你有機會直接到數據庫，它更容易）。我沒有風險在我的開發PC上運行一個指向prod數據庫的代碼：D

但是我沒有Visual Studio的經驗，所以我不確定你可以在你的情況下應用類似的東西，但我希望它可以給你一些想法。

Answer 4

我們正在開發一個分佈式存儲系統，通過我們的單元和集成測試，我們可以發現許多類似的問題，這些測試可以在每個版本中運行。另外，我們使用ReviewBoard，讓其他開發人員在提交之前查看任何更改。下一步是持續集成服務器（jenkins），它可以自動部署和測試不同環境中的工件。最後，我們的最後一道防線是我們的壓力測試測試平臺，它在任何新版本發佈前都會運行。 當然，有一個模擬您的生產環境儘可能好的測試平臺是非常重要的，但是如果您始終部署在同一個託管服務提供商處，那就不應該太難。

• 關於你的特殊情況下，如果在一個文件中的變化可能已經被遺忘在了別人，等：我想這將是安靜容易與測試腳本自動檢查。

• 未提交的更改應該是很容易檢測到的「git的差異大師」，或無論您使用的VCS。

• 要知道哪些端口需要開放的服務似乎更像是一個比配置管理的適當證件的問題。

許多使用我們系統的網站也使用puppet來管理其不同節點的配置。我不確定這是否會成爲您的選擇，但可能值得一看。

Answer 5

這聽起來像你有一個足夠小的環境中，可以很容易地使用Ansible templates或SaltStack管理所有的配置文件。

Answer 6

看一下配置http://www.configapp.com。它的工作方式是導入一個名爲web.config的基本配置文件。然後從webapp中，您將創建4個環境，dev，test，acc和prod。轉到開發環境，創建您的環境變量，並設置適合環境的值。您將只使用環境變量維護一個配置文件。您可以查看所有環境變量，並輕鬆查看環境之間的差異。

由於您只有1個配置文件需要管理，因此您將減少錯誤。當你添加一個新的通用/靜態配置時，所有的環境都會神奇地擁有這個新的設置。添加變量配置時，只需轉到正確的環境選項卡並在其中設置值即可。您可以查看所有環境的特定配置值，以便快速檢查是否遺漏了某些內容。您也可以在每個環境中查看每個配置文件，因爲它們都在您的面前。您不需要對每臺服務器使用RDP/SSH。

您不會忘記檢入，因爲Config將成爲主副本，並且不會再直接編輯配置文件。如果你直接編輯它們，我們有一個diff功能，所以你可以看到主和本地副本之間的差異。您可以使用適合您團隊的各種部署模型將主副本部署到本地服務器。您可以推，手動拉，自動拉或導出/複製。

我們將支持自定義類型，我們今後可以添加的一件事是端口數據類型。端口驗證的一部分將檢查端口是否打開。這隻能使用本地計劃，因爲它需要訪問內部網絡。或者你可以手動檢查它。轉到端口環境變量，並顯示當前配置的所有端口。檢查列表中的每個端口。如果端口看起來不錯，請在Config中添加一條評論，表示該端口已打開，並在特定日期進行檢查。 Config專門用於搜索和文檔。順便說一下，我是Config團隊的一員。