Hi,
ich bin gerade dabei eine kritische Anwendung mit dem Jenkins zu deployen. Kritisch daher, weil wenn die API nicht läuft 500 Kollegen aus unserem System gesperrt werden. Dabei hab ich ein Logikproblem beim automatischen Patchen des Datenbankschemas. Ich möchte daher möglichst viel automatisieren, da der Prozess eben heikel ist & ich menschliche Fehler ausschließen will.
Folgendes bisher:
1.) Jenkins holt Anwendung aus dem SVN
2.) Jenkins zippt Anwendung
3.) Jenkins schiebt ZIP per SSH auf Zielmaschine
4.) Jenkins stößt auf Zielmaschine Deploymentskript (Ant) an
4 a.) Deploymentskript entpackt ZIP
4 b.) Deploymentskript "konfiguriert" die Anwendung; sprich ersetzt Platzhalter durch umgebungsabhängige Werte (z.B. Datenbank Passwort, Pfade etc.)
4 c.) Deploymentskript setzt Symlink auf prelive-Umgebung
4 d.) Deploymentskript startet API-Unittests auf prelive-Umgebung
4 e.) Deploymentskript setzt Symlink auf live-Umgebung
Der Datenbankschemapatch (also wenn ich die Datenbankstruktur in einer Anwendungsversion angepasst habe) ist hier bisher noch nicht vorgesehen.
Irgendwo an dieser Stelle möchte ich aber eine Möglichkeit zum automatischen Patchen des Datenbankschemas einbauen.
Meine Idee:
1.) mysqldump live > live.sql
2.) mysql DROP DATABASE IF EXISTS test
3.) mysql CREATE DATABASE test
4.) mysqldump test < live.sql
5.) Test Datenbankschema patchen
(keine Fehler, dann weiter)
6.) Live Datenbankschema patchen
Nur wo einfügen?
Das Problem ist, dass Prelive und Live keine unterschiedliche Konfiguration haben (build.properties). Das hat a) den Vorteil, dass ich haargenau das teste, was später live geht, aber b) den Nachteil, dass ich mit den Unittests die neue, zu deployende Anwendung (prelive) unter Verwendung der alten Datenbank (noch live) teste. Das geht derzeit zwar noch gut, weil ich die Datenbankstruktur der kritischen API fast nie anfasse, aber das könnte sich natürlich ändern.
Habt ihr hier einen Ansatz für mich? Sollte ich unterschiedliche Konfigurationen für prelive und live einführen aber damit riskieren, dass prelive nicht mehr aussagekräftig ist, ob die Version live später auch funktionieren wird?
Versteht ihr meine Problematik?
Findet ihr das automatische Patchen der Datenbankstruktur überhaupt sinnvoll?
Das automatische Patchen mache ich übrigens so:
Jede Datenbank hat eine Tabelle _version. Im SVN sind *.sql-Dateien, z.B. patch-1.7.1-1.8.0.sql, patch-1.8.0-1.9.0.sql. Der Jenkins würde bisher alle Patchdateien auf die Zielkiste kopieren und ein Skript von mir erstellt eine Patchqueue von "aktueller Version" (_version) bis höchstene gefundene Version. Dann würde er alle Patchdateien der Patchqueue ausführen. Man könnte also in einem Step 1.7.1 auf 1.9.0 updaten. Solche Versionssprünge kommen gelegentlich vor, wenn Anwendungsupdates zusammengefasst werden und nicht einzeln ausgerollt werden (gerade weil der Prozess etwas heikel ist und wenn die Updates nicht wirklich dringend sind).
Wie deployt ihr?
Wie patcht ihr das Datenbankschema?
ich bin gerade dabei eine kritische Anwendung mit dem Jenkins zu deployen. Kritisch daher, weil wenn die API nicht läuft 500 Kollegen aus unserem System gesperrt werden. Dabei hab ich ein Logikproblem beim automatischen Patchen des Datenbankschemas. Ich möchte daher möglichst viel automatisieren, da der Prozess eben heikel ist & ich menschliche Fehler ausschließen will.
Folgendes bisher:
1.) Jenkins holt Anwendung aus dem SVN
2.) Jenkins zippt Anwendung
3.) Jenkins schiebt ZIP per SSH auf Zielmaschine
4.) Jenkins stößt auf Zielmaschine Deploymentskript (Ant) an
4 a.) Deploymentskript entpackt ZIP
4 b.) Deploymentskript "konfiguriert" die Anwendung; sprich ersetzt Platzhalter durch umgebungsabhängige Werte (z.B. Datenbank Passwort, Pfade etc.)
4 c.) Deploymentskript setzt Symlink auf prelive-Umgebung
4 d.) Deploymentskript startet API-Unittests auf prelive-Umgebung
4 e.) Deploymentskript setzt Symlink auf live-Umgebung
Der Datenbankschemapatch (also wenn ich die Datenbankstruktur in einer Anwendungsversion angepasst habe) ist hier bisher noch nicht vorgesehen.
Irgendwo an dieser Stelle möchte ich aber eine Möglichkeit zum automatischen Patchen des Datenbankschemas einbauen.
Meine Idee:
1.) mysqldump live > live.sql
2.) mysql DROP DATABASE IF EXISTS test
3.) mysql CREATE DATABASE test
4.) mysqldump test < live.sql
5.) Test Datenbankschema patchen
(keine Fehler, dann weiter)
6.) Live Datenbankschema patchen
Nur wo einfügen?
Das Problem ist, dass Prelive und Live keine unterschiedliche Konfiguration haben (build.properties). Das hat a) den Vorteil, dass ich haargenau das teste, was später live geht, aber b) den Nachteil, dass ich mit den Unittests die neue, zu deployende Anwendung (prelive) unter Verwendung der alten Datenbank (noch live) teste. Das geht derzeit zwar noch gut, weil ich die Datenbankstruktur der kritischen API fast nie anfasse, aber das könnte sich natürlich ändern.
Habt ihr hier einen Ansatz für mich? Sollte ich unterschiedliche Konfigurationen für prelive und live einführen aber damit riskieren, dass prelive nicht mehr aussagekräftig ist, ob die Version live später auch funktionieren wird?
Versteht ihr meine Problematik?
Findet ihr das automatische Patchen der Datenbankstruktur überhaupt sinnvoll?
Das automatische Patchen mache ich übrigens so:
Jede Datenbank hat eine Tabelle _version. Im SVN sind *.sql-Dateien, z.B. patch-1.7.1-1.8.0.sql, patch-1.8.0-1.9.0.sql. Der Jenkins würde bisher alle Patchdateien auf die Zielkiste kopieren und ein Skript von mir erstellt eine Patchqueue von "aktueller Version" (_version) bis höchstene gefundene Version. Dann würde er alle Patchdateien der Patchqueue ausführen. Man könnte also in einem Step 1.7.1 auf 1.9.0 updaten. Solche Versionssprünge kommen gelegentlich vor, wenn Anwendungsupdates zusammengefasst werden und nicht einzeln ausgerollt werden (gerade weil der Prozess etwas heikel ist und wenn die Updates nicht wirklich dringend sind).
Wie deployt ihr?
Wie patcht ihr das Datenbankschema?
Kommentar