版本控制的生產環境

Question

我的問題是，如何以良好的方式版本控制生產環境？

這是我們目前的環境：

• （內部服務器）開發 - 版本控制源代碼
• （客戶服務器）驗收測試環境
• （客戶服務器）臨時環境
• （客戶服務器）生產環境

當我們發佈接受新功能ance測試，我們在Visual Studio中進行發佈，壓縮更改並將其應用到測試服務器上。在那裏，我們創建了一個備份文件夾（以便我們可以恢復更改），並製作發佈文件夾，以便我們在批准時將這些更改移至暫存。

這是大量的手工勞動創建備份文件夾，釋放文件夾，重新創建目錄結構，並嘗試跟蹤什麼功能進入什麼版本。這是很費時的，並且一些開發者沒有遵循釋放過程總是有問題。

---

在理論上我可以讓測試環境的存儲庫。 （忘記源代碼，這是關於已發佈的應用程序）在每個版本中，開發人員都會進行提交併提供有關他正在發佈的功能的評論。

當功能應從測試移動到分段時，我們導出從上次更新分段環境進行更新並將其複製到分段應用程序中。在那裏我們做了一個提交，稍後可以將其提交到生產環境。

這樣做的缺點是使用Subversion會使應用程序與這些.svn目錄混亂。這可以通過禁止訪問IIS或web.config中的這些目錄來修補。另一種解決方案是在應用程序根目錄上的目錄中使用Git。但Git很難與Windows環境中的無經驗的開發人員一起工作。

有沒有人有這個問題的經驗？您如何版本控制您的生產環境？如果您需要恢復發行版，那麼您是否有發佈之前創建的備份文件夾？

我已經與我們的開發人員討論過這個問題，他們看不到使用Subversion進行測試/臨時/生產環境的版本控制和備份的任何問題。相反，他們會很高興不要在每次需要發佈新功能時都創建發佈/備份文件夾。

同時對此也有一些不安全感。之前沒有人聽說過這個，在版本控制系統中有應用，我們不確定會有什麼缺點。

如果您有這種情況的經驗，我很樂意聽到它。

的Mikael倫丁

Answer 1

我已經使用mercurial（汞柱）作爲生產版本控制系統。 （不是代碼，但實際部署的二進制文件）。 這工作得很好。 Subversion在我的場景中使用不太正確，因爲我確實希望能夠將生產更改（如配置文件）同步回測試甚至是開發。顛覆很難在不同的倉庫之間同步/合併（大量的手動應對）。 與hg標籤和hg更新有一個微風恢復到穩定（或不穩定）的標籤。

哦，我完全同意，你應該使用buildserver（cruisecontrol.net）或其他東西，並保留所有的東西。 我的情況是不夠的，因爲客戶生產系統的配置是自定義特定的，甚至是廣泛的測試，什麼不可能有一些配置不再在兩個版本之間做同樣的事情（或傳入的數據已經發生了很大的變化）

Answer 2

另一種做事的方法是使用構建服務器。每次檢入代碼時，構建服務器都會在開發環境中構建並打包新構建。然後用代碼檢查可部署的程序包。

然後，您可以將打包的版本部署到其他環境。這樣，您不必在那裏備份版本，因爲您已經擁有主存儲庫中的所有內置版本。如果確保部署完全自動化並且可以使用一個命令（powershell？）完成，則不需要在服務器上保留備份。

這實際上比您提出的解決方案更好，更易維護。因爲構建的每個版本都與代碼一起保存，所以您始終可以爲任何構建包找到完整的開發環境。如果您單獨版本控制您的服務器，並且在某處發現錯誤，則很難找到導致該錯誤的代碼版本。

Answer 3

謝謝你的回答和建議。

我看到我需要重新考慮處理這些環境的發佈方式。擁有所有版本的構建服務器可以解決問題的一部分。我將得到關於源代碼的提交評論，並更好地控制什麼功能進入什麼構建。我仍然需要跟蹤在什麼環境下什麼樣的版本能夠在出現問題時恢復發佈。

@Jonke 我會看看Mercurial。如果您有一個構建系統，其中每個版本都有版本控制的源代碼，那麼版本控制的生產環境可能會過度殺傷。但是，如果在部署新功能期間出現任何問題，我仍然希望能夠快速恢復到之前版本的更改。我還喜歡在服務器上獲得版本控制配置文件的方式，因爲生產環境始終與開發環境具有不同的配置。

也許我尋找的銀彈:)

Answer 4

我們用顛覆的方式來部署的事情對我們的不同的服務器（產品，演示，開發等），並沒有遇到任何困難。唯一需要注意的是數據庫差異和配置文件差異。配置文件可以進行模板化，以免覆蓋每個不同部署中的文件，但是您沒有獲得針對該特定平臺更改的版本。

通過這種系統，您可以使用subversion的標籤輕鬆更新/回滾到特定的部署版本。