Ratet nicht, was ich will! Fehlersuche an der falschen Stelle.

Fehlersuche in einem komplexen Environment ist doch immer wieder schön. Neulich habe ich wieder viel zu viel Zeit beim Debuggen verbracht, weil Änderungen in meinem Code einfach nicht in der Seite zu sehen waren. Liegt es am Redis? Am Smarty Template-Cache? Am Deployment, das ich von PhpStorm automatisch auf den DevServer machen lasse? Liegt es daran, dass ich an der nginx-Config herumgespielt habe?

Am Ende stellte sich heraus: Es war ein Zusammenspiel mehrerer Faktoren. Und da zwei davon nicht offensichtlich sind, erwähne ich sie hier.

Deployment von Dateien in .gitignore

Wir haben im Repository eine Skeleton-Datei für die nginx-Config, die wir umbenennen und in der wir die für den Entwickler passenden Werte eintragen. Die umbenannte Datei liegt im .gitignore und wird somit nicht mit eingecheckt. Also im Prinzip wie z.B. bei DotEnv-Dateien von Symfony auch.

Doch was macht PHPStorm beim Deployment daraus? Das Anlegen der Datei hat er noch mitgekriegt, und die leere Datei deployed. Den Inhalt allerdings deployed er nicht – die Datei ist ja ignoriert.

Ich habe auf dem Server somit die Datei gefunden, in /etc/nginx/sites-enabled verlinkt und nginx reloaded.

Meine Seite erscheint im Browser, schien alles zu passen. Aber wieso hat das geklappt, obwohl die Config ja gar nicht deployed wurde? Das liegt an WTF Nummer Zwei:

NGINX-Default-Server

Wenn NGINX keinen passenden Server findet der die Anfrage beantworten kann, dann nimmt er einfach den ersten definierten Server – siehe http://nginx.org/en/docs/http/request_processing.html. Anstatt eines „404 – Nicht gefunden“ habe ich also eine Antwort vom Code des nächstbesten Kollegen bekommen. Das scheint dann erstmal zu passen – aber nur bis ich eine Änderung mache, und die Auswirkungen davon nicht sichtbar sind…

 

Beide Mechanismen sind aus meiner Sicht ein WTF wert, der Eine sieht eher nach Bug aus, der Andere ist ein dickes konzeptionelles WTF.

Zuerst zum kleinen WTF: Warum sollen Dateien nicht deployed werden, nur weil sie im .gitignore stehen? OK, bei .idea- und .git-Folder macht das Sinn, aber nicht bei allen ignorierten Dateien. Außerdem hat das Deployment eine eigene Ausschlussliste:

Hier werden zwei Konzepte vermischt, die nur auf den ersten Blick dasselbe bedeuten.

Und die Datei anzulegen, aber leer zu lassen ist besonders ärgerlich – da die Datei da war ging ich davon aus, dass das Deployment funktioniert hat.Das kann daran liegen, dass der Fehler auch nur sporadisch nachvollziehbar ist. Die Erkennung ignorierter Dateien scheint nicht stabil zu laufen, und meine Testdatei hatte plötzlich auf dem Server doch einen Inhalt. In PhpStorm erschien die Warnung „You are editing a file which is ignored“ nicht mehr.

 

Das große WTF macht aus meiner Sicht NGINX: Do not guess!

Liebe Softwarehersteller, das alte Prinzip „Bullshit in, Bullshit out“ war gut. Wenn eine Config, eine HTML-Datei, whatever, … fehlerhaft ist, dann zeigt einen verdammten Fehler an. Idealerweise keine Microsoft-Fehlermeldung (Error 0 – Something went wrong!), sondern etwas Aussagekräftiges. So wie git zum Beispiel:

Aber bittebittemitsahneobendrauf, ratet nicht, was der Anwender möglicherweise gewollt hat. Das führt zu vollkommen kaputten Parsern, denn wenn Version n+1 Eures Tools anders rät als heute,  dann kracht es plötzlich bei ganz vielen Kunden, und die Fehlersuche geht los. Oder es entsteht HTML-Code wie zu „Internet Explorer 6“-Zeiten:

 <h1>Some text with <em>invalid</h1> markup</em>

Bei so etwas sollte ein Browser die Seite einfach nicht darstellen, und nicht raten, was der Nutzer wohl wollte.

Do not guess. Tut es einfach bitte nicht!

About the author

IT-Teamleiter bei CHECK24.
Hasst es, Dinge selber zu tun, die auch automatisch gehen.
Will nie wieder Code von Hand formatieren müssen.
Will schon beim Schreiben merken, wenn er Blödsinn macht, nicht erst im Fehlerlog nach dem Deployment.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen