（太）複雜的配置管理（Java屬性）

我在一家公司工作的有（過）複雜的配置管理過程：（太）複雜的配置管理（Java屬性）

在每個模塊有一個application.properties文件。存在用於開發類似的屬性：像database.host = localhost
屬性，其變化在其他環境中被保持在一個覆蓋的屬性文件夾中的文件application.properties（對於每個模塊）：[email protected]@
有一個默認部署。屬性用默認值文件爲其他環境中，如：database.HOST = noValueConfigured.DB_HOST
甲postconfigure.properties文件與DATABASE_ [email protected][email protected]

這些文件時，才需要，如果屬性值取決於環境（對於不同的開發，測試，直播）。

最後有一個具有每個環境的片材和類似的行中的Excel文件：configure.DB_HOST - a comment ... - 127.0.0.1（正如例子）。 Excel負責爲rpm包生成正確的屬性文件。

該過程不僅複雜，而且容易出錯。如何簡化/改進？

該方法應與Spring DI相兼容。

來源

2016-04-25 mosquito87

我將從主配置文件開始，並生成屬性文件以開始。

最終，您可以擁有一套可在所有環境中部署的proprties文件，例如

database.host = localhost 
database.host.prod = proddb1 
database.host.uat = uatdb1

即在最後使用環境/主機/區域/服務作爲搜索路徑。這具有可以看到環境之間的差異的優點。

您可以實現此收集這樣

public class SearchProperties extends Properties { 
    private final List<String> searchList; 

    public SearchProperties(List<String> searchList) { 
     this.searchList = searchList; 
    } 

    @Override 
    public String getProperty(String key) { 
     for (String s : searchList) { 
      String property = super.getProperty(key + "." + s); 
      if (property != null) 
       return property; 
     } 
     return super.getProperty(key); 
    }

你可以構建這個喜歡

Properties prop = new SearchProperties(Arrays.asList(serverName, environment));

這樣一來，如果有該服務器的匹配，它將覆蓋，環境這將超過默認值。

在Java 8，你可以做

public String getProperty(String key) { 
    return searchList.stream() 
      .map(s -> key + "." + s) 
      .map(super::getProperty) 
      .filter(s -> s != null) 
      .findFirst() 
      .orElseGet(()-> super.getProperty(key)); 
}

來源

2016-04-25 08:08:05

如果屬性值不依賴於環境（也就是說它們在dev，test和live上是相同的），那麼它們只是輸入到application.properties文件中，而沒有其他地方。只有他們依賴於環境，他們必須在所有這些文件中指定。 – mosquito87

@ mosquito87或者你可以按照我的建議做，並將它們全部放在同一個文件中，這樣你就可以看到每個應用程序在不同環境之間的變化，只有一個文件。 –

好的，這是一個想法，我會建議。謝謝。 – mosquito87

應該有隻有一個文件，即使它有很多的屬性。另外，每個功能應該只有一個屬性，如database.host，而不是database.host和database_host，或任何類似的東西。

您需要爲此類和每個屬性創建層次結構，以便知道哪一個屬於用戶。例如，如果database.host有一些頭部全局值，則應該使用該屬性。如果不是，請檢查層級中的下一個級別，如特定環境（如生產值）。如果不存在，請檢查下一個級別，如本地或測試級別。而對於底層，有一個默認值。通過這種方式，您具有消費屬性的兩個維度，因此可以顯着降低錯誤發生的機率。

在我曾經工作過的一家公司，我們有自動化的部署人員來處理這樣的關卡設置，我們只需在其網站上設置我們想要的變量，然後從上到下設置它們。我們從來沒有遇到過這樣的設置問題，我們在app.properties文件中會有超過50個變量。

來源

2016-04-25 08:16:23

（太）複雜的配置管理（Java屬性）

回答

相關問題