2008-10-07 96 views
8

現在我們的測試和生產數據庫位於同一臺服務器上,但名稱不同。部署意味着編輯Web.config以更改正確數據庫的所有連接字符串。一個我忘記太頻繁的步驟...如何在部署ASP.NET網站時處理連接字符串?

我們終於創建了一個新的數據庫服務器進行測試,並且我將數據庫移動到了......但現在服務器將會不同,我們仍然會需要處理連接字符串問題。

我正在考慮通過主機文件來管理它,但是當我需要對生產數據進行測試時,在桌面計算機上切換它的想法看起來很麻煩。

所以我只是想知道是否有更好的出路。東西會建立一個「生產」的web配置部署將是理想...

回答

1

有獨立CONFIGS環境的文件夾爲每個環境

部署了一個正確的環境

5

我通常有三個獨立的Web配置:一個用於我的開發機器,一個用於QA,另一個用於生產。開發人員連接到我的本地SQL數據庫(從外部防火牆),它是默認的web.config。其他人被命名爲web-prod.config和web-qa.config。發佈後,我刪除了我不需要的兩個,並將正確的一個重命名爲web.config。如果我忘了,應用程序第一次嘗試訪問數據庫時會中斷,因爲默認配置引用了它無法訪問的配置。

因爲IIS拒絕提供名爲.config的文件,所以我確定它們都以.config而不是web.config-prod或web.config-qa結尾。

+0

這些數據庫太大而無法在SQL Express中運行......但我認爲我可以使用我們的防火牆來確保生產版本不會連接到錯誤的數據庫。 – CodeRedick 2008-10-08 14:09:27

+0

我有本地安裝的SQL Server的開發者版本,而不是SQL Express。無論如何,我絕不會在我的本地系統上擁有整個生產數據,只是一些測試數據。 – tvanfosson 2008-10-08 16:03:36

1

我經常這樣做,我只在生產服務器上對web.config進行了只讀。

6

使用Web Deployment Project並更新wdproj文件(它只是一個MSBuild文件)與一些後構建任務輸出正確的.config文件。我把一個web.config和web.release.config然後在wdproj文件中使用此:

<Target Name="AfterBuild"> 
    <Copy Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' " SourceFiles="$(SourceWebPhysicalPath)\web.release.config" DestinationFiles="$(OutputPath)\web.config" /> 
    <Delete Files="$(OutputPath)\web.release.config" /> 
</Target> 

More information

一個簡單的辦法有的喜歡用configSource property of appSettings and connectionStrings從來就不是覆蓋生產服務器上的文件。

+0

我應該認爲這與VS2008中的「Web Setup Project」是一樣的嗎?看起來這可能是一個好主意... – CodeRedick 2008-10-07 21:38:01

2

這裏是另一回事,你可以嘗試:

使用SQL Server配置管理器,使數據庫別名爲您的開發數據庫,​​以便在web.config文件可以在你的開發框和生產服務器都相同。

0

我將我的連接字符串放在我們的QA和生產框中的machine.config中。不過,我會將它們保存在我的開發盒中的web.config中以獲得靈活性。然後,在部署到QA時,我將使用Web部署項目來覆蓋我的開發連接字符串(沒有任何連接字符串)。因此,QA站點依賴於machine.config中的連接字符串。我仍然手動部署到Production,以確保一切順利。我通過手動將QA中的所有內容(web.config除外)複製到生產環境來實現此目的。

2

我在每臺服務器上創建一個數據庫別名來指向數據庫。然後我在我的web.config文件中使用這個別名。如果我需要更改應用程序指向的數據庫,則更改別名而不是web.config。

對於SQL Server,請轉到SQL Server配置管理器> SQL本機客戶端配置>別名>創建新別名。

您可以使用tnsnames文件對Oracle執行相同的操作。

0

這種類型的任務正是構建事件旨在解決的問題。考慮爲特定目標構建構建,應該在那裏完成任何目標特定配置。 (與正常的警告說,總是有一些例外的規則)

1

我一直在幾個地方,現在將他們存儲在註冊表中。

現在可能有更復雜的方法來做到這一點,但我已經使用1.0/1.1遺產的很多代碼在註冊表中存儲了字符串。

註冊表有幾個優勢

  1. 它使人們從代碼部署到錯誤的地方,因爲沒有正確配置的機器將缺乏鍵
  2. 它消除了其中一個開發人員不小心打包的問題web.config文件中包含開發連接字符串(接着在半夜瘋狂地打電話,其中顯示深夜系統管理員沒有備份先前的web.config並且開發人員不知道或回想起生產字符串)
  3. 它限制了位置黑客能否通過從機器上取回web.config來獲取連接字符串。此外,註冊表具有比文件系統更高級別的安全性。
1

我們從CI服務器驅動部署。我們通常爲每個位置都有一個單獨的文件,並根據傳遞的參數將CI服務器切換到適當的配置。所有的文件編輯都是在NAnt腳本中完成的,因此開發人員可以在他們的機器上運行sam構建以獲取他們自己的設置。

0

我最近一直傾向於持續集成服務器上的配置操作。這是因爲我們遇到了多個web.config,web.qa.config,web.production.config等問題,請保持95%的文件應該保持同步。

簡而言之:在源代碼控制中只有一個web.config,它是開發配置(調試友好的,本地數據庫等)。構建服務器執行編譯,然後部署到金絲雀網站,然後進行發佈候選軟件包。

我們使用nant,所以它是.build文件,它具有設置debug =「false」的xmlpoke,alter connection字符串以及其他需要在canary副本中更改的內容以及web.config的打包副本。

構建機器的部署被稱爲「canary」,因爲如果出現問題,它首先會死亡。