Oz Linden über die Behebung von JIRA-Reports

Quelle: Oz Linden/SL Forum

Im Deploy Thread der vergangenen Woche gab es ja einigen Verdruss, dass der Fehler mit den falschen Zeitstempeln bei den Gruppenbenachrichtigungen nur auf einem einzelnen RC-Kanal gefixt wurde und es noch einmal eine Woche dauert, bis das Problem auf allen Regionen beseitigt ist.

Daraufhin hat Oz Linden kurz aber verständlich erklärt, wie der Fix dieses speziellen Problems und der Fix eines JIRA-Reports im Allgemeinen abläuft. Ich übersetze das einfach mal, weil es zum Verständnis der wöchentlichen Rolling Restarts beiträgt.

Oz Linden schrieb:

Der Code, in dem das Gruppendatumsproblem gefunden wurde, war derselbe, der die Änderungen für Avatarnamen möglich machte. Ich kann mich nicht daran erinnern, ob wir diskutiert haben, die Veröffentlichung wegen des Problems mit dem Gruppendatum zu blockieren oder nicht. Aber ich vermute, wenn wir das getan hätten, hätten wir entschieden, dass es wichtiger ist, die Namensänderungen herauszubringen. Normalerweise ziehen wir Code nur sehr selten zurück, aber alles ist ein Kompromiss - es gibt nur wenige bindende Regeln.

Im Allgemeinen dauert es selbst bei einem ziemlich wichtigen Problem ein paar Wochen, bis der Fix vom Entwickler zum Hauptkanal im Grid gelangt. Sogar nachdem der Fix vom Entwickler programmiert und getestet wurde (wobei die Zeit dafür recht unterschiedlich lang sein kann), muss er zur Prüfung an die Qualitätssicherung gehen, um getestet zu werden. Und das Codepaket muss einen allgemeinen Qualitätspass erhalten, um dann nach Regressionen zu suchen.

Je nachdem, was sonst noch in der Warteschlange steht (die ist in letzter Zeit aufgrund von Arbeiten im Zusammenhang mit der Cloud-Migration ziemlich überfüllt), kann das zwischen einem Tag und mehreren Tagen dauern. Danach kommt das Codepaket an einem Mittwoch in einen RC-Kanal. Je nach Grad des Risikos, das unserer Meinung nach in dem Paket enthalten ist (abhängig davon, welche Änderungen sich darin befinden), kann das ein kleiner Kanal sein, der nur wenige Regionen enthält, bis hin zu einem Kanal, der einen wesentlichen Teil des Grids ausmacht.

Wenn es sich um eine risikoreiche Änderung handelt, wird sie nach einer Woche von einem kleinen Kanal üblicherweise in einen oder mehrere der größeren RC-Kanäle umgeleitet und dort bleibt der Code mindestens eine weitere Woche. Normalerweise kann nur eine Version, die in mindestens einem der größeren RC-Kanäle veröffentlicht wurde, in den Hauptkanal übernommen werden. Gleichzeitig werden diese Änderungen dann auch in die Codepakete aller RC-Kanäle integriert, so dass die Änderung zu diesem Zeitpunkt überall verfügbar ist.

Die Entscheidungen darüber, welche Codepakete in welchen Kanälen eingesetzt werden sollen, werden von einem Team getroffen, das sich aus Vertretern der Bereiche Produkt, Entwicklung, Qualitätssicherung, operatives Geschäft und Support zusammensetzt. Es wird niemals von einer einzelnen Person entschieden.

Was Oz mit "kleine RC-Kanäle" meint, sind zwei Kanäle, die üblicherweise nicht im wöchentlichen Deploy Thread erwähnt werden. Die heißen "Snack" und "Cake" und in jedem dieser Kanäle sind nur weniger Regionen. Bei früheren öffentlichen Ankündigungen waren das so zwischen 4 und 16 Regionen. Die "großen RC-Kanäle" sind die mit den Namen BlueSteel, LeTigre und Magnum. Jeder besteht aus 10% aller Regionen im Grid. Aktuell wären das dann 5.000 Regionen pro Kanal.

Quelle: [Deploy Thread] - Deploy Plans for the week of 2020-05-18