在版本控制下處理系統特定信息的最佳實踐是什么？

Question

我是版本控制的新手，所以如果有一個眾所周知的解決方案我會道歉。 特別是對於這個問題，我正在使用git，但我很好奇如何處理所有版本控制系統。

我正在開發服務器上開發Web應用程序。 我已經在兩個地方定義了Web應用程序的絕對路徑名（而不是文檔根目錄）。 在生產服務器上，此路徑不同。 我對如何處理這件事很困惑。

我可以：

1. 重新配置開發服務器以共享與生產相同的路徑
2. 每次更新生產時編輯兩次出現。

我不喜歡＃1，因為我寧願讓應用程序靈活應對未來的任何變化。 我不喜歡＃2，因為如果我開始使用第三個路徑開發第二個開發服務器，我將不得不為每次提交和更新更改它。

處理這個問題的最佳方法是什么？ 我想到了：

1. 使用自定義關鍵字和變量擴展（例如在版本控制屬性中設置屬性$ PATH $並在所有文件中展開它）。 Git不支持這一點，因為它會帶來巨大的性能損失。

2. 使用更新后和預提交掛鈎。 可能是git的可能解決方案，但每次我查看狀態時，它都會報告這兩個文件被更改。 不太干凈。

3. 從版本控制之外的配置文件中提取路徑。 然后我必須將配置文件放在所有服務器上的相同位置。 也可能只有相同的路徑開始。

有一個簡單的方法來處理這個？ 我在想它嗎？

Answer 1

不要對文件系統路徑等配置數據進行硬編碼，並強制要求多個部署匹配。 那是黑暗的一面，那里有很多的苦難。

我覺得構建我的系統很容易並且很容易支持多種配置，並且我經常將配置文件並行提交到源代碼控制中，但是生產是混淆的（沒有真正的密碼），並且開發是模板化的（所以結賬可以' t覆蓋開發人員的配置）。 代碼總是以與配置無關的方式打包 - 可以在任何地方部署相同的二進制文件。

不幸的是，大多數語言/開發平台都不支持這一點（與Ruby on Rails不同）。 因此，你必須在不同程度上自己構建它。

通常，基本原則是將間接合並到您的配置中：在代碼中指定不是配置，而是如何查找配置。 並且通常調用幾個間接：特定於用戶，特定於應用程序，特定於機器，特定於環境。 每個都應該以明確定義的位置/方式找到，並且它們之間應該有一個非常明確的優先級（通常是用戶通過機器而非應用程序而不是環境）。 您通常會發現每個可配置設置都在一個位置具有自然主頁，但不要將該依賴項硬編碼到您的應用程序中。

我發現設計應用程序以報告其配置並進行驗證非常有價值。 在大多數情況下，丟失或無效的配置項應導致中止應用程序。 盡可能在啟動時執行該驗證（並中止）=快速失敗。 硬編碼默認僅在可以可靠使用時才會出現。

摘要配置訪問，以便大多數應用程序不知道它來自何處或如何處理。 我更喜歡創建Config類，將可配置設置作為單獨的屬性公開（在相關時強類型化），然后我通過IOC將它們“注入”應用程序類。 不要讓所有應用程序類直接調用所選平台的原始配置框架; 抽象是你的朋友。

在大多數企業級（財富500強）組織中，除了該環境的管理團隊之外，沒有人會看到生產（甚至測試）環境配置。 配置文件永遠不會在發行版中部署，它們由管理團隊手動編輯。 相關的配置文件肯定永遠不會與代碼並排檢查到源代碼控制中。 管理團隊可以使用源代碼管理，但它是他們自己的私有存儲庫。 Sarbanes-Oxley和類似法規也傾向於嚴格禁止開發人員訪問（近）生產系統或任何敏感配置數據。 在設計方法時要小心。

請享用。

Answer 2

您應始終將部署歷史記錄（源代碼管理的用途）分開。

部署涉及：

• 一組已識別的數據（由SCM提供的標簽或標簽派上用場）
• 操作這些數據的過程（至少在正確的位置復制它們，但也擴展一些壓縮文件，等等......）

在部署的各種操作中，您應該包括一個去變量階段。

變量是一個關鍵字，表示可能會根據您的部署平台（可以是用於持續集成的PC，用於基本認證的Linux，用於預生產認證的舊Solaris8以及具有生產區域的完整F15K Solaris10）可能發生變化的任何內容：它很短，它可以變化很多）。 請參閱Jonathan Leffler對實際例子的回答 。

變量可以表示路徑，JVM版本，一些JVM設置等等，您在SCM中放置的內容應該是包含變量的數據，而不是硬編碼設置。

下一步是在可執行文件中包含一種方法來檢測設置文件中的任何更改，以便在運行某些參數時進行更新（避免所有“關閉/更改設置/重新啟動”序列）。
這意味着它們是兩種類型的部署變量 ：

• 靜態的（永遠不會改變），
• 動態的（在運行時會話期間應該理想地考慮）

Answer 3

盡可能避免使用絕對路徑。

不要依賴當前的版本控制來做一些神奇的事情 - 您可能會在將來更改版本控制系統。

最簡單的方法對我有用：有一個'config.live'並且'config'被配置用於開發。 在部署期間，只需將config.live移動到config，一切都很好。 對於更復雜的配置，可能需要每個配置的子目錄。

一組部署過程是必不可少的 - 因為配置只是一個不同的區域。

任何更復雜的東西幾乎肯定會導致比它解決的問題更多的問題。

Answer 4

使用Git等SCM進行版本控制，使用Capistrano等部署工具進行部署 。 雖然Capistrano最初是為Ruby on Rails創建的，但將它用於其他框架和語言是完全可以的。

主要的是，特定的部署工具將為您提供所有靈活性，以自動化兩端的路徑。

Answer 5

我喜歡Ruby on Rails處理這類問題的方式 - 特定於環境的配置文件。 Rails支持開發，測試和生產數據庫連接 - 由database.yml文件中的配置控制。 這是一篇關於創建其他特定於環境的配置選項的博客文章，它適用於Rails，但可能會為您提供有關如何為您的環境執行類似操作的一些想法。 http://usablewebapps.com/2008/09/yaml-and-custom-config-for-rails-projects/

Answer 6

聽起來你的生產代碼是一個完整的git存儲庫和更新生產你做一個git pull ？ 您可能希望嘗試單獨的構建過程來檢查存儲庫中的代碼並創建一個干凈的構建（沒有.git文件夾）。 您可以擁有特定於環境的配置文件，其中包含與其一起復制或創建的路徑。