Beispiel für Login

[1unitedpower]

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).

Versionskontrollsysteme bieten in aller Regel die Möglichkeit Dateien auf eine schwarze Liste zu setzen, die dann nicht versioniert werden. In git wäre das die .gitignore-Datei in SVN gibt es diverse Möglichkeiten. Das kann und sollte man auch tun, wenn man sich dafür entscheidet seine Deploy-spezfische Konfiguration in Dateien zu verwalten, die im Dateisystem zusammen mit dem Code-Repository leben. Und man muss es sogar tun, wenn das Code-Repostory öffentlich ist. Sauberer ist meiner Meinung nach der Ansatz der 12-Factor-App bei dem man Code-Repository und Deploy-spezfische Konfiguration vollständig voneinander trennt. Wenn solche Konfigurations-Daten gar nicht im Dateisystem zusammen mit dem Code-Repository leben, dann erleichtert das ja die Versionskontrolle und das Deployment.

Außerdem abstrahieren DALs auch andere Pfade die nicht ins eigenen Dateisystem zeigen wir z.B. UNC oder URI.

Die kann man ebenfalls in Umgebungsvariablen packen und so sauber vom Code-Repository trennen.