Bugfixing ist ein langwieriger, aber obligatorischer Bestandteil jeder Entwicklung, und nicht jeder möchte es tun. Wie kann man Bugfixing in etwas Aufregendes verwandeln? Vereinbaren Sie einen Wettbewerb! In diesem Beitrag werden wir ausführlich über unseren 24-Stunden-Bugfix-Marathon sprechen - von der Vorbereitung bis zur Durchführung der letzten Commits nach der Vergabe der Gewinner.
Infiziert mit der Idee
Der Entwicklungsumfang unserer Sberbank Online-Anwendung hat im vergangenen Jahr erheblich zugenommen. Gleichzeitig häuften sich kleine Fehler, die sich in keiner Weise auf die wichtigsten Metriken auswirkten. Aber wir haben verstanden, dass dies eine Zeitbombe ist und etwas damit getan werden muss.
Wir waren begeistert davon, wie unsere
Avito- Kollegen solche Probleme lösen, und beschlossen, einen massiven Angriff auf Fehler im Bagaton-Format zu organisieren - unter Berücksichtigung unserer Entwicklungsstruktur, Kultur und Besonderheiten des Flusses.
Es war notwendig, alles so zu arrangieren, dass die Jungs selbst an einem Bagaton teilnehmen und ihre Coolness ohne Anweisungen von oben beweisen wollten. Dazu sollte der Wettbewerb eine coole Atmosphäre haben. Wir haben uns entschlossen, einen besonderen Stil zu entwickeln, der an Fehlern erkennbar ist. Bugs sind Bugs. Wer zerstört Käfer im normalen Leben? Desinsektoren sind Männer in gelben Chemikalienschutzanzügen. Wo wurden sie in den letzten Jahren beleuchtet? In einer beliebten Serie über einen Chemielehrer. Es gibt eine Basis, wir beenden mit Aktivitäten. Sie organisierten ein Videospiel-Turnier, ein Quiz mit Preisen, coole individuelle Nominierungen ... und natürlich viel leckeres Essen. Aber die Hauptsache, was auch immer man sagen mag, ist die Konkurrenz um die Beseitigung von Fehlern. Dies wurde an ein Dashboard mit einer Weboberfläche erinnert, das den Fortschritt der Teams, ihre aktuellen Positionen, die Anzahl der Punkte usw. anzeigt. Wir haben alles mit den Teamleitern besprochen - sie haben unsere Pläne gebilligt.
Android vs iOS - so unehrlich
Zunächst wollten wir die Android-Entwickler von Sberbank Online mit ihren iOS-Kollegen dazu bringen, die Rivalität der Plattformen zu nutzen. Dabei erkannten die Unternehmen, dass dies nicht die beste Lösung ist, da die Plattformen technisch unter ungleichen Bedingungen funktionieren. Unter iOS sind Builds schneller und es werden Autotests ausgeführt.
Dann haben wir das Format geändert und gemischte Teams gebildet: jeweils fünf Android- und iOS-Entwickler. Zuvor wurden unter proaktiven Entwicklern Kapitäne ausgewählt, um Teams zu bilden. Es stellte sich heraus, neun Teams. Und trotz der Tatsache, dass wir das Eisenproblem unter dem Gesichtspunkt des Fairplay herausgefunden haben, mussten wir immer noch sicherstellen, dass andere Einschränkungen unserer Armee von Bugfixern nicht im Wege stehen.
Die nächste Aufgabe war die Wahl des Bagaton-Datums. Die Veröffentlichungstermine für jede Plattform sind unterschiedlich - sie wurden so ausgewählt, dass sich alle wohl fühlten. Wir haben versucht, das Datum so nah wie möglich an das Datum zu bringen, an dem der Release-Kandidat zugewiesen wird.
Darüber hinaus belastet bagaton die Plattforminfrastrukturen stark. Wenn es eine Konkurrenz gibt, die Fehler schneller behebt, nimmt die Anzahl der Pull-Anfragen ab. Weitere anderthalb Monate vor dem Bagaton bestand das Risiko, dass unsere Ausrüstung die vorhergesagten Spitzen nicht bewältigen konnte. Aber in diesem Moment erwarteten wir neues Eisen und es kam gerade noch rechtzeitig an. Wir haben es mehrmals geschafft, die Bandbreiteninfrastruktur beider Plattformen zu verbinden, zu konfigurieren und zu stärken.
Pipeline - wie man nicht alles in ein Rohr absenkt
Hier wurde alles wie folgt gemacht: Unmittelbar vor Beginn des Bagatons aus unserer Entwicklung nahmen wir den Zweig, in dem die Teams arbeiten mussten. Während des Bagatons wurden viele Pull-Anfragen mit behobenen Fehlern hineingegossen. Auf jedem von ihnen wurden Autotests ausgeführt, Entwickler überprüften Pull-Anforderungen und Tester überprüften neue Builds, um den Fehler zu beheben. Und so alle 24 Stunden des Wettbewerbs.
Es war auch notwendig, die Last der Tester zu verteilen. Wir haben ein Stundendiagramm der vorhergesagten Anzahl von Pull-Anforderungen im 24-Stunden-Bagaton-Intervall erstellt - abhängig von der Anzahl der Teilnehmer, der Serverlast, Aktivitäten von Drittanbietern usw. Verglichen mit der durchschnittlichen Leistung der Tester und der Anzahl der effektiven Stunden jedes begleitenden Bagatons. Wir haben die "Pflicht" so verteilt, dass am Samstagmorgen so wenig Linien wie möglich vorhanden waren. Im Allgemeinen wurden sie verwirrt.
Gleichzeitig haben wir berücksichtigt, dass nach dem Bagaton sofort mit Regressionstests begonnen werden musste, um die Qualität des Zweigs so schnell wie möglich zu bewerten und über seine Infusion in den Entwicklungszweig zu entscheiden. Dies ist eine zusätzliche Belastung für Tester.
Funktionsüberprüfung
Es war uns sehr wichtig, Fehler nicht nur zu beheben, sondern auch qualitativ zu tun. Drei Verfahren ermöglichen die Überprüfung des Codes, der von Entwicklern in Pull-Anforderungen gesendet wird. Damit der Code einrastet, müssen sie erfolgreich übergeben werden:
- Drei erfahrene Entwickler haben den Code überprüft und genehmigt.
- Der Code stürzte normalerweise ab und schlug die Autotests nicht fehl.
- Nach dem Build und der Infusion wird der Fehler in der Assembly unter den beschriebenen Bedingungen nicht fortgesetzt.
Wir befürchteten, dass sich im Wettbewerbsmodus niemand gegenseitig überprüfen würde. Und innerhalb des Teams können Sie keine Bewertung abgeben. Deshalb haben sie beschlossen, nichts zu erfinden und nach dem Standardablauf zu handeln, wie im Arbeitsmodus: eine willkürliche Gegenprüfung - wer frei ist, nimmt den Prozess auf sich.
Es war auch notwendig zu verfolgen, damit die Bewertungen nicht in die Warteschlange gingen. Um auf Nummer sicher zu gehen, haben wir Unterzeichner für die Überprüfung gewonnen (auch diejenigen, die nicht am Bagaton selbst teilgenommen haben) und die Teilnehmer aktiv an die Ausrichtung auf Qualität erinnert. Ein leitender iOS-Entwickler hat parallel zur Behebung von Fehlern für sein Team an einem Tag 80 Pull-Anfragen erhalten - er hat gelesen und verstanden. Das ist wirklich viel!
Wir wählen und bewerten Fehler
Wir haben Fehler mit niedriger Priorität behoben und offensichtlichen Müll durch Etiketten und Daten beseitigt. Insgesamt stellten sich 490 Fehler heraus - meist kleine und mittlere, die die Hände aufgrund wichtigerer Aufgaben nicht erreichten. Dies sind alles vernünftige Kleinigkeiten und Minderjährige:
- Fehler, die wiederholt von Version zu Version verschoben wurden
- Fehler sind auf Benutzeranfragen aufgetreten
- frischester Absturz
- Regressionsfehler
- Fehler, die UX betreffen
Alle Bugs wurden entsprechend der Abschlusspriorität in drei Wellen unterteilt:
- Die erste Welle - ungefähr 230 Bugs
- Die zweite Welle - ungefähr 150 Bugs
- Die dritte Welle (Reserve) - ungefähr 110 Bugs
Mängel wurden nicht nach Komplexität, sondern nach Kritikalität für das Unternehmen bewertet. Die kritischsten sind "künstlich" und werden vorübergehend in die Prioritäten "Blocker" und "kritisch" gesetzt. Je höher die Priorität des Fehlers, desto mehr Punkte wurden dafür vergeben. Die Komplexität wurde nicht berücksichtigt - es kam vor, dass der Bugblocker in 20 Minuten und das Triviale in 4 Stunden geschlossen wurde. Für einen Fehler können Sie 1 bis 7 Punkte verdienen.
Wir haben die Punktzahl jedes Teams für geschlossene Bugs gemäß ihrem Wert in den Bagaton-Regeln beibehalten. Wenn die Teams Zeit hatten, nahmen sie den folgenden Defekt in Angriff. Motivation durch Wert ermöglichte es, in erster Linie kritischere Fehler zu schließen.
So schließen Sie Fehler
Wir haben die erste Fehlerwelle in 11 Gruppen (mit einem Rand) unterteilt, die in der Anzahl der Punkte und im Verhältnis von Android und iOS gleich sind. Die erste Welle sind "teure" Fehler, vorrangige mit erhöhten Kosten. Für eine bequeme Suche in Jira haben wir ihnen die entsprechenden Bezeichnungen zugewiesen. In jeder Gruppe wurden ungefähr 20 Bugs veröffentlicht.
Zu Beginn des Bagatons versammelten wir Mannschaftskapitäne und spielten Labels. Außerdem haben die Kapitäne in ihrem Filter das gewünschte Etikett festgelegt und die entsprechenden Fehler innerhalb des Teams verteilt. Also haben wir es geschafft, chaotische Bugfixes zu eliminieren, bei denen die Jungs einfach das nehmen würden, was für sie verständlicher ist.
In den ersten vier Stunden erhielten die Teams nur Punkte für Fehler mit den Labels der Gruppe, die ihnen zugefallen waren, um einen bestimmten Rhythmus festzulegen. Als die Zeit abgelaufen war, gingen die noch offenen Käfer in die zweite Welle über und fügten den anderen hinzu, die Sinn machten, innerhalb des Bagatons zu schließen.
Um 19:00 Uhr gingen alle nicht geschlossenen Bugs in die dritte Welle - zusätzlich zu den Bugs, die dort bereits geplant waren. Infolgedessen hatten wir für den Abend „schnelle“ Fehler, die im üblichen Ablauf geschlossen wurden: Caches und aktuelle, die buchstäblich einen Tag vor dem Bagaton entladen wurden, sowie Fehler mit der niedrigsten Priorität. Alle drei Wellen gingen zur Arbeit. Infolgedessen wurden 286 von 493 ausgewählten Fehlern für Bagaton geschlossen.
Bagaton vereint sich
Das Bagaton-Hauptquartier befand sich in unserem Konferenzraum, es gab auch Quiz und ein Videospiel-Turnier. Die Teams waren nicht begrenzt, verstreut, wo immer es ihnen passt. Infolgedessen erfuhr die gesamte Bank von Bagaton. Ein Produkt-Ooner aus dem vierten Stock sagte: „Ich werde mich im 14. Stock treffen und nach dem richtigen Besprechungsraum suchen. Plötzlich verstehe ich, dass ich gerade bekannte Gesichter gesehen habe, ich komme zurück - meine Entwickler sitzen Figuren mit Macht und Kraft und ohne Aufmerksamkeit für mich. Ha - ich denke - sie werden sich nicht vor ihrem Produktbesitzer und über 10 Stockwerken verstecken, okay, sitzen Sie schon, der Bugfix ist eine richtige Sache. “
Es gab ein Team, in dem nur ein Android zum Bagaton kam und gleichzeitig sechs starke iOS-Entwickler. Wir haben dieses Team ausnahmsweise um ein weiteres Paket mit iOS-Bugs geschlagen.
Außerdem kamen sieben Entwickler aus den Regionen zu Bagaton. Einige trafen ihre Teams zum ersten Mal, was sie zuvor nur per Videokonferenz gesehen hatten. Es war sehr cool zu sehen, wie sich diese Jungs aktiv dem Prozess angeschlossen haben.
Wie wurden die Ergebnisse bewertet?
Für fast hundert Entwickler hatten wir nur 15 Tester. Und nachts gibt es überhaupt vier. Alle waren nicht genug, daher wurden die Tests am nächsten Tag fortgesetzt. Es waren die Tester, die den Teams Punkte verliehen haben, deshalb haben wir sie aus dem Team entfernt, um Verzerrungen zu beseitigen. In einem normalen Workflow kann der Tester den Entwickler anrufen und herausfinden: "Hören Sie, Alter, es gibt ein solches Problem ...". Beim Bagaton war es streng: Tester sollten alles einwickeln, was nicht klar ist.
Wir konnten also feststellen, dass einige Entwickler nicht im akzeptierten Ablauf arbeiten. Der Hackathon ist zu einer Art Katalysator für alle Abweichungen geworden. Diejenigen, die klar im Fluss arbeiten, haben es geschafft, die Tests in der ersten Welle zu bestehen und Punkte zu bekommen. Alle, die nicht wirklich korrespondierten, standen in der Warteschlange, die sie bereits nach dem Bagaton geharkt hatten. Es hat 60 Fehler.
Vorfälle
Im Allgemeinen verlief alles wie gewohnt, die Vorfälle waren typisch und funktionierten ordnungsgemäß. Als etwas kaputt ging, wechselten einige der Unterzeichner sofort vom Bugfix zur Beseitigung des Vorfalls.
Es gab einen lustigen Vorfall. Bei der Vorbereitung des Dashboards haben wir die möglichen Risiken beschrieben: Zugriff auf Jira, fortlaufende Updates usw. Sie teilten allen Administratoren mit, dass für die Zeit des Bagatons alle Wartungsarbeiten, Aktualisierungen von Jira und Server ausgesetzt werden mussten. Sicherungskonten für den Zugriff auf Jira erstellt. Und plötzlich, gegen 18:00 Uhr, stellen wir fest, dass das Dashboard keine Daten mehr sammelt. Die Annahmen waren unterschiedlich. Vielleicht haben sie ein Sicherheitsprotokoll nicht berücksichtigt? Der Grund war unerwartet. Unsere Organisation ist sehr groß, es ist nicht immer möglich, vollständige Informationen über alle geplanten Prozesse zu erhalten. Unser Dashboard wurde auf einer virtuellen Maschine auf einem der sekundären Server bereitgestellt. Es stellte sich heraus, dass an diesem Tag, Freitagabend, dieser Server nach einem unbekannten Plan physisch von der Steckdose getrennt, in das Auto geladen und an einen dauerhaften Wohnsitz in unserem neuen Rechenzentrum geschickt wurde. Infolgedessen mussten wir bis Samstagmorgen alle Daten sammeln und Punkte im manuellen Modus berechnen.
Zweige und andere Ergebnisse zusammenführen
Im normalen Betriebsmodus wird der gesamte Zweig manuell von mehr als 800 Testfällen gesteuert. Ein komplettes Testerteam führt unsere Vollzeit-Regressionstests in zwei Wochen durch. Wir konnten es uns nicht leisten, uns so lange unverändert weiterzuentwickeln. Um die Testzeit zu verkürzen, haben wir die wichtigsten Testfälle für den Zustand der Anwendung ausgewählt - etwa 107. Bis Ende Montag haben sie 80% von iOS, 50% von Android betrieben und keinen einzigen kritischen Fehler festgestellt. Wir haben beschlossen, dass die Zweige zusammengelegt werden können.
Von den 286 auf dem Bagaton geschlossenen Fehlern wurden 182 Fehler behoben. Der Rest sind Redjacks, die aus verschiedenen Gründen nicht relevant sind, Fehler (irgendwo hat sich das Design oder die Funktionalität bereits geändert). Diese Fehler sind nicht kritisch, aber jetzt müssen sie nicht mehr abgelenkt werden und Sie können sich ruhig auf wichtige Aufgaben konzentrieren.
Außerdem hatten viele nach den Ergebnissen von bagaton eine Frage: Wie viele Fehler haben wir gemacht? Nur acht Fehler unter iOS und sieben Fehler unter Android.
Für uns ist es wichtig, dass sich Entwickler gleichermaßen wie andere Teammitglieder für den Produktcode verantwortlich fühlen. Dies ist in jeder Entwicklung wichtig, wird jedoch in der verteilten Entwicklung zur Voraussetzung für eine erfolgreiche Arbeit. Und unserer Meinung nach haben wir es geschafft, das Niveau der gleichen Eigenverantwortung und des gleichen Teamgeistes zu steigern. Das Ergebnis war eine Geschichte mit einer Menge Gewinn: In kurzer Zeit haben wir eine Reihe von Fehlern behoben, Rückstände entladen, Teamfähigkeiten gepumpt und viel Fan bekommen.
Vom Team der Sberbank Digital Business Platform vorbereitetes Material