Huhu zusammen,

ich hab mir mal ein paar Ideen gemacht was ganz gut als Deployment Prozess für den produktiven Server dienen könnte.

Premises des ganzen ist dass Spieler aktiv auf einer lauffähigen Version des Servers spielen, aber trotzdem nebenher parallel an dem Server gearbeitet wird. Ist eine neue Version getestet und spielbar wird diese nach "Produktion" deployed, also den Spielern zur Verfügung gestellt.

Dafür würde ich den Development Server, sobald er fertig ist für ein release, mit Docker als eigenes Image packen und das dann taggen. Dieses Image enthält alle Konfigurationen, einen Auszug der Datenbank Tabellen welche Konfigurationen enthalten und die Welt. Beim Start werden dann der SQL Dump in die Datenbank gespielt und die Welt kopiert.

So könnte man nur mit einem "docker run tjoa/server:1.0.0" den kompletten Server starten.

Vorteil davon wäre auch dass man die diversen spielbaren Versionen alle archiviert hat und jederzeit ein Rollback oder Nostalgie Besuch möglich wäre.

Was meint ihr?

Zitat von Rincewind

Das klingt mega gut und sinnvoll. Am besten wäre es, man an den Deployment Prozess noch irgendwie ein SQL Script anhängen könnte, dass die Datensätze konvertiert. Es wäre durchaus im Bereich des möglichen, dass sich die Datenbankstrutkur zwischen zwei Versionen mal ändern. Mehr als eine neue Spalte oder eine Tabelle ist zwar unwahrscheinlich, sollte aber trotzdem mit bedacht werden.

Das gehört aus meiner Sicht in die Plugins und sollte dort mit Migrations gelöst werden. Ich verwende dafür z.B.: bei allen meinen Plugins diesen ebean-wrapper hier: Releases · Silthus/ebean-wrapper (github.com) (DB Migration | Docs | Ebean)
Denn nur das Plugin weiß ja was für Daten, Spalten sich ändern und kann diese migrieren.

Zitat von Rincewind

Wir bräuchten dann außerdem noch eine Lösung für BugFixes. Was ich mir da spontan vorstellen könnte, wäre ein Development Server, auf dem dann aktiv an der neuen Version gearbeitet wird und ein Server, an dem BugFixes vorgenommen werden. Wäre jetzt noch die Frage, wie die BugFixes auch auf dem DevelopmentServer gebracht werden, ohne "Menge-Konflikte" zu erzeugen. Kleinere Sachen kann man einfach so auf beiden machen, aber bspw. ein Bug in einer Quest zu fixen, kann dann schonmal auch ne halbe Stunde Arbeit sein.

Ja das müsste man sich überlegen. Ich denke wenn man bei Bugixes Block Änderungen in der Welt ausschließt kann man einfach die Git History mergen. Wenn SQL Änderungen dabei sind muss man schauen wie man es macht.