Patch-Release Prozeduren
Posted: Fri Mar 18, 2005 11:25 pm
Patch-Release Prozeduren
Als Nachfolge auf den Artikel Neuigkeiten von den Entwicklern werde ich hier nun im Detail beschreiben wie die Prozeduren zum Release eines Patches aussehen - in anderen Worten, um zu beschreiben, wie Content, Features und Fixes die Live-Version erreichen. Die Idee hierhinter ist es euch ein besseres Bild darüber zu geben, wie wir arbeiten um Veränderungen ins Spiel einzubringen; was unser grober Zeitablauf ist und wie Probleme, die während der Testphase entdeckt werden, unsere Zeitpläne beeinflussen.
Ich habe hier zwei Prozeduren zu erklären: die für Grosspatches, die neuen Content, Features und Fixes in einem Paket bringen, und Kleinpatches, die benutzt werden um kleine Fixes schnell Live zu bringen. Am Ende werde ich diese Theorie mit einem konkreten Beispiel illustrieren: dem Patch von letzter Woche.
A] Prozedur von Grosspatches
Diagramm 1 : Prozedur von Grosspatches
ID | Aufgaben | Bearbeiter
1 | Vorbereitung der Spezifikationen | Event-Team, Boss- und Riten-Designteams, Guil
2 | Entwicklungsarbeit | Alle Entwicklungsteams
3 | Erstellung eines neuen Zweigs und Builds auf dem Testserver | Datenmanager
4 | Lieferung an das Testteam | Datenmanager
5 | Test- und Debugarbeiten | Testteam + die entsprechenden Entwicklungsteams
6 | Überprüfung | mind. 2 Personen, entweder Guil, Vince oder Daniel
7 | Kommunikation mit den Spielern | CSR-Teams
8 | Patch auf die Event-Server | Datenmanager + Eventteam
9 | Patch auf die Live-Server | Datenmanager + CSR-Teams
10 | ATS grünes Licht zum Patchen | mind. 2 Personen, entweder David B., Guil oder Daniel
11 | ATS Patch | Datenmanager + CSR-Teams
Wie ihr seht gibt es 3 Phasen:
1) Entwicklung
Die erste Phase, die Entwicklung, beinhaltet die Arbeit verschiedener Teams: die Programmierer, die Leveldesigner, die 3D-Künstler, etc. Sie haben verschiedene Arbeitstechniken, welche jeweils an die Arbeiten angepasst sind, die sie durchführen müssen. Zum Beispiel benutzen die Coder eine adaptierte Untermenge der Extremen Programmierungstechniken (besonders die Kapitel: Planning Game, Small Releases, Simple Design and Design Improvement). Sie bekommen regelmässig einen Satz Aufgaben, der ungefähr 2 Wochen Arbeit entspricht: die Iteration.
Am Ende der Iteration eines Programmierers werden alle Code-Änderungen und die Arbeit der anderen Teams zusammengenommen und als Zweig markiert: dies ist im Prinzip nur eine interne Versionnummer die dem aktuellem Code und Content zugewiesen wird. Das Format dabei ist X_Y_Z, X steht für die Hauptversionnummer(momentan 1), Y für die Kapitelnummer(momentan 2) und Z für die aktuelle Zweignummer seit dem letzten Kapitel(momentan 7). Von den Entwicklern geschriebene Notizen dokumentieren den veränderten Code und werden zusammengestellt um die Veränderungen am aktuellem Zweig festzuhalten: die Zweignotizen; sie sind im Grunde genommen eine technische Version der Releasenotizen.
2) Tests
a) Einfacher Regressionstest
Das Erste, was das Entwicklerteam beim Testen eines neuen Zweigs tut ist das Durchführen eines Regressionstests. Zwei Tage lang gehen die Tester eine einfache Checkliste durch um sicherzugehen, dass die grundlegenden Systeme korrekt arbeiten, da Software, die so komplexx wie ein MMORPG ist, anfällig gegenüber dem Schmetterlingseffekt ist, der besagt, dass kleine Variationen in einem dynamischen System grosse Folgen nach sich ziehen können.
Wenn in dieser Phase ein wichtiges Problem gefunden wird, wird an einem Fix gearbeitet und die Version wird noch noch einmal getestet bevor sie in die nächste Phase eintritt. Dies kann grosse Verzögerungen verursachen, aber es ist nötig um zu vermeiden, dass die ATS-Version zu sehr beschädigt wird.
b) Tiefe interne Tests & ATS
Dann, wenn alles korrekt funktioniert wird ein Patch erstellt und auf dem ATS angewendet. Die internen Tester führen ihre Tests fort und gehen durch eine detaillierte Checkliste von existierenden und neuen Spielmechanismen, welche auf standartisierten Checklisten und Zweignotizen basiert.
Während interne und ATS-Tests durchgeführt werden, werden Bugs gefunden und andere Probleme identifiziert. Für jedes Problem gibt es drei verschiedene Fälle: wenn der Fix klein, schnell udn sicher genug ist wird es sofort behoben; das entsprechende Feature wird im aktuellen Zweig ausgeschaltet und auf den nächsten verschoben; oder der Patch wird verzögert, wenn die Abhängigkeiten der erforderlichen Veränderungen zu gross sind. Die grundlegende Zeitlinie hier ist zwei Wochen, aber auch dies kann abhängig von den Testergebnissen verängert werden.
Wenn alles korrekt funktioniert treten wir in die finale (und stressigste) Phase ein: den Live-Patch.
3) Live-Patch
Hier ist das Erste was wir tun, den Patch anzukündigen (auf den Boards udn nun auch in den News). Dann werden der Patch und die Releasenotizen vorbereitet, und letztendlich werden die Server am angekündigtem Datum und Uhrzeit heruntergefahren udn der Patch angewendet.
Während die Server gepatcht werden nutzen die Systemadministrationsteams die Zeit um die Linuxserver zu updaten und ein komplettes Backup vom Spiel vor dem Patch anzufertigen.
Wenn die Server dann gepatcht und bereit sind, werden sie von den CSR-Teams einem letzten Check unterzogen, und... tada! Ihr könnt endlich die Früchte unserer harten Arbeit geniessen.
B] Kleinpatch Prozedur
Diagramm 2 : Ninjapatch Prozedur
ID | Aufgaben | Bearbeiter
1 | Wöchentliches Treffen um bekannte Probleme zu besprechen | mind. 2 Personen, entweder Guil, Vince oder Daniel
2 | Einzeltreffen um neue Probleme zu besprechen | mind. 2 Personen, entweder Guil, Vince oder Daniel
3 | Briefing der Entwicklungsleiter zu den Problemen auf dem Live-Server | Guil oder Daniel
4 | Debugging | Entwicklungsteams
5 | Schnellrevue der Fix-Auswirkungen und Überprüfung für den Live-Patch | Entwicklungsleiter und Guil oder Daniel
6 | Anwendung des Fixes auf alle notwendigen CVS-Zweige | Entwicklungsteams
7 | Kompilierung und Test | Datenmanager und Testteam
8 | Ankündigung an die Gms | CSR-Teams
9 | Patch auf die Live-Server | Datenmanager + CSR-Teams
Wie jeder MMORPG-Spieler weiss, gibt es so etwas wie ein perfektes MMO-Spiel, oder gar Patch, nicht. Es ist also nötig eine Reaktionsprozedur bereit zu haben um mit dringenden Problemen auf den Live-Servern umzugehen. Ihr würdet nicht wollen, dass wir die Iterationsrelease-Prozedur dafür verwenden, da ihr ein paar Wochen warten müsstet, bis ein Fix aufgespielt wird!
Daher haben wir einen Weg, der als "der sicherste Weg zum schnellsten Fix" beschrieben werden kann. Wenn ein dringender Fix benötigt wird, gibt es einen feinen Grat zwischen Geschwindigkeit und Sicherheit, da Sicherheit Tests erfordert und Zeit in Anspruch nimmt. Daher gibt es hierfür keine grobe Zeitlinie, denn diese ist davon abhängig was behoben wird.
Früher in den Tagen direkt nach Release hatten wir eine haarsträubende Reaktionsprozedur(die wir intern Ninja-Patch nannten
). Ein paar der Entwickler werden mitten in der Nacht angerufen, kriechen aus dem Bett, beheben ein Problem und machen den Patch innerhalb von 10-20 Minuten fertig! Aber, wie bereits in Neuigkeiten von den Entwicklern beschrieben, waren die fehlende Entwicklungszeit und Testzeit auf lange Sicht nicht ohne Konsequenzen für das Spiel. Selbst der einfachste Fix benötigt Tests bevor er auf den Live-Server losgelassen werden kann. Daher haben wir aufgehört Ninja-Patches zu entwickeln und die Kleinpatch-Prozedur adaptiert.
Schritt für Schritt sieht die Kleinpatch-Prozedur folgendermassen aus:
Um die Theorie zu illustrieren gibt es nichts besseres als ein bischen kionkreter zu werden: hier werde ich die Patches der letzten Woche Revue passieren lassen(53, 55, 56).
1) Patch 53 - Grosspatch-Prozedur
Zwei Probleme wurden in aufeinanderfolgenden Patches behoben. Es gab ein sprach-abhängiges Problem mit den Namen der Mounts an einigen Stellen im Spiel. Dies war ein Übersetzungsproblem und wurde tatsächlich schon einige Zeit bevor der Patch Live ging behoben. Jedoch wurde dem Fix von den Testern noch kein grünes Licht gegeben, daher zogen wir es vor den Hauptpatch nicht zu verzögern. Die Korrigierung erforderte nur einen Client-Patch und wurde daher später am selben Tag(10. März) ohne Unterbrechung der Serverdienste angewendet. Wenn neue Spieler sich einloggten wurde der Patch angewendet, während die anderen auf 53 blieben, bis sie sich ausloggten.
Nach dem Patch entdeckten wir ein weiteres Problem, dass die Crafting-Werkzeuge betraf. Da dieses Problem trivial war und wir sichergehn wollten, dass die Korrektur einen korrekten Testzyklus durchlief, reagierte das CSR-Team augenblicklich indem es den Spielern kostenlosen Ersatz bereitstellte. Dieser Fix wurde mit ein paar anderen Punkten in einen Kleinpatch verbunden und gestern gepatcht (Patch 56).
--
Xavier.
Als Nachfolge auf den Artikel Neuigkeiten von den Entwicklern werde ich hier nun im Detail beschreiben wie die Prozeduren zum Release eines Patches aussehen - in anderen Worten, um zu beschreiben, wie Content, Features und Fixes die Live-Version erreichen. Die Idee hierhinter ist es euch ein besseres Bild darüber zu geben, wie wir arbeiten um Veränderungen ins Spiel einzubringen; was unser grober Zeitablauf ist und wie Probleme, die während der Testphase entdeckt werden, unsere Zeitpläne beeinflussen.
Ich habe hier zwei Prozeduren zu erklären: die für Grosspatches, die neuen Content, Features und Fixes in einem Paket bringen, und Kleinpatches, die benutzt werden um kleine Fixes schnell Live zu bringen. Am Ende werde ich diese Theorie mit einem konkreten Beispiel illustrieren: dem Patch von letzter Woche.
A] Prozedur von Grosspatches
Diagramm 1 : Prozedur von Grosspatches
ID | Aufgaben | Bearbeiter
1 | Vorbereitung der Spezifikationen | Event-Team, Boss- und Riten-Designteams, Guil
2 | Entwicklungsarbeit | Alle Entwicklungsteams
3 | Erstellung eines neuen Zweigs und Builds auf dem Testserver | Datenmanager
4 | Lieferung an das Testteam | Datenmanager
5 | Test- und Debugarbeiten | Testteam + die entsprechenden Entwicklungsteams
6 | Überprüfung | mind. 2 Personen, entweder Guil, Vince oder Daniel
7 | Kommunikation mit den Spielern | CSR-Teams
8 | Patch auf die Event-Server | Datenmanager + Eventteam
9 | Patch auf die Live-Server | Datenmanager + CSR-Teams
10 | ATS grünes Licht zum Patchen | mind. 2 Personen, entweder David B., Guil oder Daniel
11 | ATS Patch | Datenmanager + CSR-Teams
Wie ihr seht gibt es 3 Phasen:
- Entwicklung
- Test (interne Tests and ATS-Tests)
- Live Patch
1) Entwicklung
Die erste Phase, die Entwicklung, beinhaltet die Arbeit verschiedener Teams: die Programmierer, die Leveldesigner, die 3D-Künstler, etc. Sie haben verschiedene Arbeitstechniken, welche jeweils an die Arbeiten angepasst sind, die sie durchführen müssen. Zum Beispiel benutzen die Coder eine adaptierte Untermenge der Extremen Programmierungstechniken (besonders die Kapitel: Planning Game, Small Releases, Simple Design and Design Improvement). Sie bekommen regelmässig einen Satz Aufgaben, der ungefähr 2 Wochen Arbeit entspricht: die Iteration.
Am Ende der Iteration eines Programmierers werden alle Code-Änderungen und die Arbeit der anderen Teams zusammengenommen und als Zweig markiert: dies ist im Prinzip nur eine interne Versionnummer die dem aktuellem Code und Content zugewiesen wird. Das Format dabei ist X_Y_Z, X steht für die Hauptversionnummer(momentan 1), Y für die Kapitelnummer(momentan 2) und Z für die aktuelle Zweignummer seit dem letzten Kapitel(momentan 7). Von den Entwicklern geschriebene Notizen dokumentieren den veränderten Code und werden zusammengestellt um die Veränderungen am aktuellem Zweig festzuhalten: die Zweignotizen; sie sind im Grunde genommen eine technische Version der Releasenotizen.
2) Tests
a) Einfacher Regressionstest
Das Erste, was das Entwicklerteam beim Testen eines neuen Zweigs tut ist das Durchführen eines Regressionstests. Zwei Tage lang gehen die Tester eine einfache Checkliste durch um sicherzugehen, dass die grundlegenden Systeme korrekt arbeiten, da Software, die so komplexx wie ein MMORPG ist, anfällig gegenüber dem Schmetterlingseffekt ist, der besagt, dass kleine Variationen in einem dynamischen System grosse Folgen nach sich ziehen können.
Wenn in dieser Phase ein wichtiges Problem gefunden wird, wird an einem Fix gearbeitet und die Version wird noch noch einmal getestet bevor sie in die nächste Phase eintritt. Dies kann grosse Verzögerungen verursachen, aber es ist nötig um zu vermeiden, dass die ATS-Version zu sehr beschädigt wird.
b) Tiefe interne Tests & ATS
Dann, wenn alles korrekt funktioniert wird ein Patch erstellt und auf dem ATS angewendet. Die internen Tester führen ihre Tests fort und gehen durch eine detaillierte Checkliste von existierenden und neuen Spielmechanismen, welche auf standartisierten Checklisten und Zweignotizen basiert.
Während interne und ATS-Tests durchgeführt werden, werden Bugs gefunden und andere Probleme identifiziert. Für jedes Problem gibt es drei verschiedene Fälle: wenn der Fix klein, schnell udn sicher genug ist wird es sofort behoben; das entsprechende Feature wird im aktuellen Zweig ausgeschaltet und auf den nächsten verschoben; oder der Patch wird verzögert, wenn die Abhängigkeiten der erforderlichen Veränderungen zu gross sind. Die grundlegende Zeitlinie hier ist zwei Wochen, aber auch dies kann abhängig von den Testergebnissen verängert werden.
Wenn alles korrekt funktioniert treten wir in die finale (und stressigste) Phase ein: den Live-Patch.
3) Live-Patch
Hier ist das Erste was wir tun, den Patch anzukündigen (auf den Boards udn nun auch in den News). Dann werden der Patch und die Releasenotizen vorbereitet, und letztendlich werden die Server am angekündigtem Datum und Uhrzeit heruntergefahren udn der Patch angewendet.
Während die Server gepatcht werden nutzen die Systemadministrationsteams die Zeit um die Linuxserver zu updaten und ein komplettes Backup vom Spiel vor dem Patch anzufertigen.
Wenn die Server dann gepatcht und bereit sind, werden sie von den CSR-Teams einem letzten Check unterzogen, und... tada! Ihr könnt endlich die Früchte unserer harten Arbeit geniessen.
B] Kleinpatch Prozedur
Diagramm 2 : Ninjapatch Prozedur
ID | Aufgaben | Bearbeiter
1 | Wöchentliches Treffen um bekannte Probleme zu besprechen | mind. 2 Personen, entweder Guil, Vince oder Daniel
2 | Einzeltreffen um neue Probleme zu besprechen | mind. 2 Personen, entweder Guil, Vince oder Daniel
3 | Briefing der Entwicklungsleiter zu den Problemen auf dem Live-Server | Guil oder Daniel
4 | Debugging | Entwicklungsteams
5 | Schnellrevue der Fix-Auswirkungen und Überprüfung für den Live-Patch | Entwicklungsleiter und Guil oder Daniel
6 | Anwendung des Fixes auf alle notwendigen CVS-Zweige | Entwicklungsteams
7 | Kompilierung und Test | Datenmanager und Testteam
8 | Ankündigung an die Gms | CSR-Teams
9 | Patch auf die Live-Server | Datenmanager + CSR-Teams
Wie jeder MMORPG-Spieler weiss, gibt es so etwas wie ein perfektes MMO-Spiel, oder gar Patch, nicht. Es ist also nötig eine Reaktionsprozedur bereit zu haben um mit dringenden Problemen auf den Live-Servern umzugehen. Ihr würdet nicht wollen, dass wir die Iterationsrelease-Prozedur dafür verwenden, da ihr ein paar Wochen warten müsstet, bis ein Fix aufgespielt wird!
Daher haben wir einen Weg, der als "der sicherste Weg zum schnellsten Fix" beschrieben werden kann. Wenn ein dringender Fix benötigt wird, gibt es einen feinen Grat zwischen Geschwindigkeit und Sicherheit, da Sicherheit Tests erfordert und Zeit in Anspruch nimmt. Daher gibt es hierfür keine grobe Zeitlinie, denn diese ist davon abhängig was behoben wird.
Früher in den Tagen direkt nach Release hatten wir eine haarsträubende Reaktionsprozedur(die wir intern Ninja-Patch nannten
). Ein paar der Entwickler werden mitten in der Nacht angerufen, kriechen aus dem Bett, beheben ein Problem und machen den Patch innerhalb von 10-20 Minuten fertig! Aber, wie bereits in Neuigkeiten von den Entwicklern beschrieben, waren die fehlende Entwicklungszeit und Testzeit auf lange Sicht nicht ohne Konsequenzen für das Spiel. Selbst der einfachste Fix benötigt Tests bevor er auf den Live-Server losgelassen werden kann. Daher haben wir aufgehört Ninja-Patches zu entwickeln und die Kleinpatch-Prozedur adaptiert.Schritt für Schritt sieht die Kleinpatch-Prozedur folgendermassen aus:
- Schritt 1: Eine Entscheidung um ein Problem mittels der Kleinpatch-Prozedur zu beheben wird getroffen.
- Schritt 2: Der Fix wird entwickelt
- Schritt 3: Die Programmierer und Tester stellen eine kurze Test-Prozedur zusammen um den Fix zu bestätigen und auf Nebeneffekte zu überprüfen.
- Schritt 4: Der Fix wird getestet bis jeder davon überzeugt ist, dass er korrekt funktioniert. Zeit ist wichtig, daher sind die Tests nicht soe tiefgehend, wie bei einem Grosspatch.
- Schritt 5: Der Patch wird auf die Live-Server gespielt und Ankündigungen werden gepostet.
Um die Theorie zu illustrieren gibt es nichts besseres als ein bischen kionkreter zu werden: hier werde ich die Patches der letzten Woche Revue passieren lassen(53, 55, 56).
1) Patch 53 - Grosspatch-Prozedur
- 18/02 : Die Programmierer beenden eine Iteration.
- 21/02 : Ein Zweig wurde erstellt und intern als 1_2_7 beziffert.
- 22/02 bis 25/02 : Der schnelle Regressionstest wird intern durchgeführt.
- 25/02 : Da der Patch gut verlief wurde das grüne Licht gegeben und der 1_2_7-Zweig auf den ATS gepatcht.
- 03/03 : Probleme mit den In-Game-Riten wurden identifiziert und daher ihre Einführung verschoben.
- 07/03 : Ein Problem mit dem /afk-Befehl wurde entdeckt, daher wurde der Befehl deaktiviert.
- 09/03 : Da keine weiteren grossen Probleme entdeckt wurden, wurde dem Patch grünes Licht gegeben um Live zu gehen. Dem Patch wurde die Nummer 53 zugewiesen und er wurde augenblicklich angekündigt.
- 10/03 : Die Releasenotizen wurden vorbereitet und wie gewöhnlich während der Server-Down-Zeit veröffentlicht, damit ihr etwas zum Lesen habt, während ihr nicht spielen könnt. Letztendlich ging der Patch dann Live.
Zwei Probleme wurden in aufeinanderfolgenden Patches behoben. Es gab ein sprach-abhängiges Problem mit den Namen der Mounts an einigen Stellen im Spiel. Dies war ein Übersetzungsproblem und wurde tatsächlich schon einige Zeit bevor der Patch Live ging behoben. Jedoch wurde dem Fix von den Testern noch kein grünes Licht gegeben, daher zogen wir es vor den Hauptpatch nicht zu verzögern. Die Korrigierung erforderte nur einen Client-Patch und wurde daher später am selben Tag(10. März) ohne Unterbrechung der Serverdienste angewendet. Wenn neue Spieler sich einloggten wurde der Patch angewendet, während die anderen auf 53 blieben, bis sie sich ausloggten.
Nach dem Patch entdeckten wir ein weiteres Problem, dass die Crafting-Werkzeuge betraf. Da dieses Problem trivial war und wir sichergehn wollten, dass die Korrektur einen korrekten Testzyklus durchlief, reagierte das CSR-Team augenblicklich indem es den Spielern kostenlosen Ersatz bereitstellte. Dieser Fix wurde mit ein paar anderen Punkten in einen Kleinpatch verbunden und gestern gepatcht (Patch 56).
--
Xavier.