Beispiel für Login

[pl]

hi,

Doch, das ist der Stand der Technik und die sicherste Variante Konfigurationen zwischen Deploys zu trennen. Die Richtlinien der Twelve-Factor-App, die ich ebenfalls verlinkt habe, haben dazu auch extra einen Abschnitt.

Wenn ein versehentliches Einchecken von Konfigurationsdateien in eine Repository das einzige Argument ist: Dem kann man auch anders begegnen, z.b. in der Anwendung zur Versionskontrolle selbst (→SVN). Außerdem abstrahieren DALs auch andere Pfade die nicht ins eigenen Dateisystem zeigen wir z.B. UNC oder URI.

Ergänzung der Vollständigkeit halber: In meinem FW haben die Quelldateien zur Konfiguration ein eigenes Repository, was vom Repository der Software vollständig getrennt ist. Das Erstellen der Konfiguration ist also Bestandteil des Deployments wobei alle Konfigurationsparameter in einer Datei zusammengefasst sind. Beim jedem Deploy wird also diese Datei neu gebildet und nach dem Neustart des Webservers befindet sich die ganze Konfiguration komplett im Hauptspeicher für den wahlfreien Zugriff (Random Access). Die Datei dient also einmal dem Transport und zum Anderen dem Webserver als Backup falls dieser neu gestartet werden muss. Optional kann dieses Backup auch in eine DB gelegt werden.

Konfiguration und Software definieren also zwei verschiedene und voneinander unabhängige Deployments und haben voneinander getrennte Repositories, das ist die Trennung. Das Laden meiner Konfiguration in den Hauptspeicher hat nicht die Trennung von der Versionskontrolle zum Ziel sondern den wahlfreien Zugriff. Die Trennung von der Versionskontrolle der Software erfolgt wie beschrieben an anderer Stelle.

MfG