(zu) komplexes Konfigurationsmanagement (Java Objekte)

Question

Ich bin an einem Unternehmen einen (zu) komplexen Konfigurationsmanagementprozess mit: es

• In jedem Modul ist eine Datei application.properties. Es gibt Eigenschaften für die Entwickler wie: database.host = localhost
• Eigenschaften, die Veränderungen in anderen Umgebungen werden in einer Datei application.properties in einem Override-Eigenschaften Ordner beibehalten (für jedes Modul) wie: database.host=@dbhost@
• Es gibt eine Standard-Implementierung. Eigenschaften mit Standardwerten für andere Umgebungen wie file: database.HOST = noValueConfigured.DB_HOST
• A postconfigure.properties mit DATABASE_ HOST=@configure.DB_HOST@

werden nur die Dateien, wenn ein Eigenschaftswert ist abhängig von den Umgebungen benötigte Datei (ist unterschiedlich für Entwicklung, Testen , Leben).

• Schließlich gibt es ein Excel-Dokument mit einem Blatt für jede Umgebung und eine Reihe wie: configure.DB_HOST - a comment ...-127.0.0.1 (wie zB). Das Excel ist verantwortlich für das Generieren der richtigen Eigenschaftendateien für die RPM-Pakete.

Dieser Prozess ist nicht nur komplex, sondern auch fehleranfällig. Wie könnte es vereinfacht/verbessert werden?

Der Ansatz sollte compatbiel mit Spring DI sein.

Answer 1

Ich würde mit einer Hauptkonfigurationsdatei beginnen und die Eigenschaftsdateien erzeugen, um damit zu beginnen.

Schließlich könnten Sie eine Reihe von Property-Dateien haben, die in allen Umgebungen bereitgestellt werden können, z.

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

d. H. Verwenden Sie die Umgebung/host/region/service am Ende als Suchpfad. Dies hat den Vorteil, dass Sie die Unterschiede zwischen den Umgebungen sehen können.

können Sie implementieren diese ähnliche sammeln

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); 
    } 

Sie könnten dieses Konstrukts wie

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

diese Weise, wenn es eine Übereinstimmung für diesen Server ist, wird es die Umwelt außer Kraft setzen, das wird überschreibt die Standardeinstellung.

In Java 8 können Sie

tun

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

Answer 2

sollte es nur eine Datei sein, auch wenn es viele Eigenschaften hat. Außerdem sollte es nur eine Eigenschaft für jede Funktionalität geben, wie zum Beispiel database.host, nicht database.host und database_host oder irgendetwas ähnliches.

Sie müssen eine Hierarchie für diese und für jede Eigenschaft erstellen, um zu wissen, welcher Benutzer sein wird. Wenn zum Beispiel ein globaler Kopfwert für "database.host" vorhanden ist, sollte er für diese Eigenschaft verwendet werden. Ist dies nicht der Fall, überprüfen Sie die nächste Hierarchieebene, z. B. bestimmte Umgebungen (z. B. Produktionswert). Wenn dies nicht der Fall ist, überprüfen Sie die nächste Stufe, z. B. die lokale Ebene oder die Teststufe.Und für die unterste Ebene haben Sie einen Standardwert. Auf diese Weise haben Sie zwei Dimensionen der konsumierenden Eigenschaften und als solche verringert sich die Fehlerwahrscheinlichkeit dramatisch.

In einer Firma, die ich arbeitete, hatten wir automatisierte Deployer, die solche Level-Setup behandeln würde, würden wir einfach Variable auf seiner Website für Level, die wir wollten, setzen und es würde von oben nach unten gehen und sie setzen. Wir hatten nie Probleme mit solchen Einstellungen und wir hätten mehr als 50 Variablen in der Datei app.properties.