Wir haben früher eine soziale Website mit einer Standard-LAMP-Konfiguration betrieben. Wir hatten einen Live-Server, einen Testserver und einen Entwicklungsserver sowie die lokalen Entwicklerrechner. Alle wurden mit GIT verwaltet.
Auf jedem Rechner befanden sich die PHP-Dateien, aber auch der MySQL-Dienst und ein Ordner mit den Bildern, die die Benutzer hochladen wollten. Der Live-Server wuchs auf etwa 100.000 (!) wiederkehrende Benutzer an, der Speicherauszug war etwa 2 GB (!) groß, der Bildordner etwa 50 GB (!). Als ich das Unternehmen verließ, stieß unser Server an die Grenzen seiner CPU, seines Arbeitsspeichers und vor allem an die Grenzen der gleichzeitigen Netzverbindungen (wir kompilierten sogar unsere eigene Version des Netzwerkkartentreibers, um den Server voll auszulasten 'lol'). Wir konnten nicht ( Sie sollten auch nicht davon ausgehen, dass Sie mit Ihrer Website ) 2 GB an Daten und 50 GB an Bildern in GIT zu speichern.
Um all dies unter GIT einfach zu verwalten, ignorierten wir die Binärordner (die Ordner mit den Bildern), indem wir diese Ordnerpfade in .gitignore einfügten. Wir hatten auch einen Ordner namens SQL außerhalb des Apache documentroot-Pfads. In diesen SQL-Ordner legten wir unsere SQL-Dateien von den Entwicklern in inkrementeller Nummerierung ab (001.florianm.sql, 001.johns.sql, 002.florianm.sql usw.). Diese SQL-Dateien wurden ebenfalls mit GIT verwaltet. Die erste sql-Datei würde in der Tat einen großen Satz von DB-Schemata enthalten. Wir fügen in GIT keine Benutzerdaten hinzu (z. B. die Datensätze der Benutzertabelle oder der Kommentartabelle), aber Daten wie Konfigurationen oder Topologie oder andere standortspezifische Daten wurden in den SQL-Dateien (und damit von GIT) verwaltet. Meistens sind es die Entwickler (die den Code am besten kennen), die bestimmen, was in Bezug auf SQL-Schema und Daten von GIT gepflegt wird und was nicht.
Wenn es zu einer Veröffentlichung gekommen ist, meldet sich der Administrator auf dem Entwicklungsserver an, führt den Live-Zweig mit allen Entwicklern und den benötigten Zweigen auf dem Entwicklungsrechner zu einem Update-Zweig zusammen und schiebt ihn auf den Testserver. Auf dem Testserver prüft er, ob der Aktualisierungsprozess für den Live-Server noch gültig ist, und leitet in schneller Folge den gesamten Datenverkehr im Apache auf eine Platzhalter-Site um, erstellt einen DB-Dump, leitet das Arbeitsverzeichnis von 'live' auf 'update' um, führt alle neuen Sql-Dateien in mysql aus und leitet den Datenverkehr wieder auf die korrekte Site zurück. Wenn alle Beteiligten nach der Überprüfung des Test-Servers zugestimmt haben, führt der Administrator das Gleiche vom Test-Server zum Live-Server durch. Anschließend führte er den Live-Zweig auf dem Produktionsserver mit dem Master-Zweig auf allen Servern zusammen und stellte alle Live-Zweige neu ein. Die Entwickler waren selbst dafür verantwortlich, ihre Zweige zu rebasen, aber sie wissen im Allgemeinen, was sie tun.
Wenn es auf dem Testserver Probleme gab, z. B. zu viele Konflikte bei den Zusammenführungen, wurde der Code rückgängig gemacht (indem der Arbeitszweig wieder auf "live" gesetzt wurde) und die SQL-Dateien wurden nie ausgeführt. In dem Moment, in dem die SQL-Dateien ausgeführt wurden, wurde dies als nicht rückgängig zu machende Aktion betrachtet. Wenn die SQL-Dateien nicht ordnungsgemäß funktionierten, wurde die DB mit dem Dump wiederhergestellt (und die Entwickler wegen der Bereitstellung schlecht getesteter SQL-Dateien verwarnt).
Heute unterhalten wir sowohl einen sql-up- als auch einen sql-down-Ordner mit äquivalenten Dateinamen, in denen die Entwickler testen müssen, ob die aktualisierenden sql-Dateien gleichermaßen heruntergestuft werden können. Dies könnte letztlich mit einem Bash-Skript durchgeführt werden, aber es ist eine gute Idee, wenn menschliche Augen den Upgrade-Prozess überwachen.
Es ist nicht großartig, aber es ist überschaubar. Ich hoffe, dies gibt einen Einblick in eine reale, praktische, relativ hochverfügbare Website. Sei es ein bisschen veraltet, aber immer noch gefolgt.
