Ankündigung

Einklappen
Keine Ankündigung bisher.

Deployment Prelive -> Live, Datenbankschema patchen

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Deployment Prelive -> Live, Datenbankschema patchen

    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?
    "[URL="http://www.youtube.com/watch?v=yMAa_t9k2VA&feature=youtu.be&t=25s"]Mein Name ist Lohse, ich kaufe hier ein.[/URL]"

  • #2
    High Available APIs patche ich nicht in den laufenden Betrieb, ich erzeuge "Schwestern" und leite wenn alles Fertig ist den DNS auf die neue Software, bzw. die PHP-Anwendung auf die neue Datenbank um.

    Die Patches an sich spielt bei uns ein Deploy-Daemon in der Farm auf, der ist selbstständig in der Lage von der Test-Datenbank die entsprechenden Änderungen zu extrahieren und den Patch zu erzeugen und via GIT zu archivieren, der erzeugt auch Datenbank-Snapshoots und wirft sie entsprechend auf den jeweiligen Host der ihn anfordert, sofern er denn dazu berechtigt ist.

    Es existiert allerdings immer eine Datenbank / Anwendung die "so ist wie sie vor dem GAU war".
    [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

    Kommentar


    • #3
      Ich würde auch eine neue DB aufbauen und dann umschalten wenn alles läuft. Sowas kann man in Firmen meist wudnerbar nachts machen, wenn die Mitarbeiter schlafen. Bei 24/7 benutzen DB's muss dann der Anwender dann halt die Zeit warten die das Installieren und Testen der neuen Version braucht oder wenn es was nutzt kann man auch der alten DB solange nur Leserechte geben, damit sie nicht mehr geändert wird.

      Gruß

      Claus
      Pre-Coffee-Posts sind mit Vorsicht zu geniessen!

      Kommentar


      • #4
        Zitat von Thallius Beitrag anzeigen
        Ich würde auch eine neue DB aufbauen und dann umschalten wenn alles läuft. Sowas kann man in Firmen meist wudnerbar nachts machen, wenn die Mitarbeiter schlafen. Bei 24/7 benutzen DB's muss dann der Anwender dann halt die Zeit warten die das Installieren und Testen der neuen Version braucht oder wenn es was nutzt kann man auch der alten DB solange nur Leserechte geben, damit sie nicht mehr geändert wird.

        Gruß

        Claus
        Bei 4x 2,6 Gbit kannst du das Tagsüber machen
        [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

        Kommentar


        • #5
          Zitat von tr0y Beitrag anzeigen
          Bei 4x 2,6 Gbit kannst du das Tagsüber machen
          Naja ich dachte wenn ich die Kopie der live DB angelegt habe. darf sich diese ja nicht mehr ändern solange bis ich die neue libe schalte. Je nachdem wieviel Tests man da erst drüber fahren läßt muss die aktuelle DB ja solange offline oder readonly sein.

          Gruß

          Claus
          Pre-Coffee-Posts sind mit Vorsicht zu geniessen!

          Kommentar


          • #6
            Bedingt, je nach Projekt / Umgebung kann man durchaus eine Live-Synchronität beibehalten, kommt halt auf die Geschwindigkeit der Infrastruktur an. Ansonsten hast du natürlich Recht.
            [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

            Kommentar


            • #7
              Zitat von Chriz Beitrag anzeigen
              Wie patcht ihr das Datenbankschema?
              http://docs.doctrine-project.org/pro...l#createschema

              ich mach das eher mit make files, also make database-sync ruft ein php script auf der dann den shema manager verwendet um mir ein migration script zu erzeugen
              apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

              Kommentar


              • #8
                Hi danke für eure Antworten. Ich bin selbst noch nicht so ganz sicher, ob von euren Tipps und eigenen Vorgehensweisen etwas für mich dabei ist. Klingt wirklich professionell, ich bin aber nicht sicher ob sich das hier so wirklich umgesetzt lässt.

                Ich melde mich wenn wir uns entschieden haben wie wir es dann machen werden.
                "[URL="http://www.youtube.com/watch?v=yMAa_t9k2VA&feature=youtu.be&t=25s"]Mein Name ist Lohse, ich kaufe hier ein.[/URL]"

                Kommentar

                Lädt...
                X