Welches ist das beste Verfahren zur Aktualisierung einer Website/Webanwendung?

Question

Wir haben ein großartiges Verfahren für die Aktualisierung der Websites unserer Kunden, was die Aktualisierung des HTML/JS-Codes und der Assets betrifft (unter Verwendung von Subversion), mit dem wir sehr zufrieden sind.

Für die Aktualisierung von Datenbanken gibt es jedoch kein formelles Verfahren.

Wenn wir unserer Entwicklungsdatenbank neue Tabellen/Felder hinzufügen, müssen wir uns beim Rollout auf den Produktionsserver an unsere Änderungen erinnern und sie replizieren. Wir können nicht einfach die Entwicklungsdatenbank auf die Produktionsdatenbank kopieren, da sonst Kundendaten verloren gehen würden (z. B. Blogbeiträge, Kontoinformationen usw.).

Wir sind auch gerade dabei, eine Web-App zu entwickeln, die auf die gleichen Probleme stoßen wird.

Hat jemand eine Lösung, die diesen Prozess einfacher und weniger fehleranfällig macht? Wie umgehen große Web-Apps das Problem?

Gracias.

Answer 1

Meiner Meinung nach ist die Einbeziehung von Kontrollen in den Entwicklungsprozess von größter Bedeutung. Bei einer meiner früheren Tätigkeiten mussten wir alle Datenbankänderungen in Skripten festhalten. Diese Skripte wurden dann an den Datenbankadministrator weitergegeben, mit der Anweisung, in welcher Umgebung sie eingesetzt werden sollten. Letztendlich kann man technische Lösungen implementieren, aber wenn das Projekt ordnungsgemäß dokumentiert ist (WENN!!!), sollten die Entwickler bei der Implementierung daran denken, die Skripte zusammen mit den Codedateien zu migrieren. Meine $.02

Answer 2

Meiner Meinung nach sollte Ihr Code immer in der Lage sein, Ihre Datenbank von Grund auf neu zu erstellen, daher sollte er auch Upgrades beherrschen. Er sollte ein Feld in der Datenbank überprüfen, um zu sehen, welche Version das Schema hat, und die Upgrades auf die neueste Version durchführen.

Answer 3

Ich hatte viel Glück damit: http://anantgarg.com/2009/04/22/bulletproof-subversion-web-workflow/

Der Autor hat einen Datenbankversionierungs-Workflow (mit PHP-Skript), der anständig ist.

Answer 4

Einige Frameworks verfügen über Tools, die sich mit dem Upgrade der Datenbank befassen. Zum Beispiel sind Rails-Migrationen ziemlich nett. Wenn kein geeignetes Tool für Ihre Plattform verfügbar ist, können Sie versuchen, Änderungen an Ihrer Entwicklungsdatenbank per Skript vorzunehmen.

In meinem Unternehmen verwenden wir dieses Modell für einige unserer größten Projekte: Wenn X die gerade bereitgestellte Version unserer Anwendung ist und sich nicht von der letzten Entwicklungsversion unterscheidet. Wir erstellen ein neues Verzeichnis für die Skripte, benennen es z.B. mit Version x + 1 und fügen es dem Subversion-Repository hinzu. Wenn der Entwickler Änderungen an der Entwicklungsdatenbank vornehmen möchte, erstellt er ein .sql-Skript mit dem Namen "1 - tut etwas.sql", das die Änderungen vornimmt (sie müssen unzerstörbar sein), speichert es und führt es dann in der Entwicklungsdatenbank aus. Er überträgt den Code der Webanwendung und die Sql-Skripte. Jeder Entwickler macht das Gleiche und hält die Reihenfolge der Ausführung der Skripte ein. Wenn wir die Version X+1 einsetzen müssen, kopieren wir den Code der Webanwendung x+1 und die Skripte auf den Produktionsserver, sichern die Datenbank, führen die SQL-Skripte nacheinander auf der Produktionsdatenbank aus und setzen den neuen Code der Webanwendung ein.

Danach öffnen wir ein neues (x + 2) Sql-Skriptverzeichnis und wiederholen den Vorgang ...

Answer 5

Wir haben im Grunde einen ähnlichen Ansatz wie Senad, wir pflegen eine changes.sql-Datei in unserem Repo, in die die Entwickler ihre Änderungen eintragen. Wenn wir in die Produktion gehen, machen wir:

Führen Sie eine Testbereitstellung auf dem QA-Server durch:

• Reproduzieren Sie zunächst die Produktionsumgebung (Anwendung und Datenbank) auf dem QA-Server.
• changes.sql gegen die QA-DB laufen lassen
• Bereitstellung der Anwendung für QA
• Integrationstests durchführen.

Wenn wir sicher sind, dass die Anwendung in QA mit den geskripteten Änderungen an der Datenbank einwandfrei läuft (d.h. niemand hat vergessen, seine Datenbankänderungen in die changes.sql einzuschließen, oder Referenzen, usw.), dann:

• Sicherung der Produktionsdatenbank
• die Skripte in der Datei changes.sql mit der Produktionsdatenbank abgleichen
• die Anwendung bereitstellen
• die Datei changes.sql löschen

Die gesamte Bereitstellung erfolgt über automatisierte Skripte, so dass wir sie jetzt reproduzieren können.

Ich hoffe, das hilft