Wie finde ich Freunde PHPstorm, xDebug und Remote-Zweige, die über Docker kompiliert wurden? Zu einfach ...

Guten Tag, Habr!

Vor einem Jahr bestand mein Prozess zum Debuggen von Code in PHP aus zwei Zeilen:

var_dump($variable); die(); 

Von Zeit zu Zeit musste ich natürlich "komplexere" Konstruktionen verwenden:

 console.log(data); 

 echo json_encode($variable, JSON_UNESCAPED_UNICODE); exit(); 

Nein, was bist du? Ich wusste - in unserer Zeit ist es für einen Kulturprogrammierer nicht angemessen, dies zu tun


Aber ehrlich gesagt hatte ich immer Angst vor dem, was ich nicht verstand. Einschließlich xDebug- Drucker , insbesondere zur Konfiguration dieser ganzen Sache. Eines schönen Tages schaffte ich es in meinem Auto und in einem lokalen Projekt - der Freude waren keine Grenzen gesetzt. Viele Monate später stieß ich auf ein neues Problem, wie man in PHPstorm über xDebug debuggt, wenn das Projekt von Docker über CI remote erstellt wird.

Wenn Sie wie ich Schwierigkeiten haben, verschiedene Dinge zu konfigurieren, begrüßen Sie die Katze. Ich werde über meine Erfahrungen beim Einrichten einer Debugging-Umgebung mit beängstigenden Worten wie Docker, xDebug, CI sprechen.

Für diejenigen, die kein Wasser mögen und direkt zur Essenz der Umgebung gehen möchten.

Warum sollten Sie sich von schimmeligen Debugging-Methoden verabschieden und auf geeignete Technologien umsteigen?

Ich habe die Katze ein wenig ausgetrickst, ich war mit handwerklichem Debuggen beschäftigt, nicht nur, weil ich Angst hatte, etwas zu konfigurieren, und nicht, weil es zu dumm war, sondern einfach, weil ich nichts Bequemeres brauchte. Meistens arbeitete ich lokal an Projekten auf meinem ziemlich leistungsfähigen Computer, und die Aufgaben waren nicht so kompliziert, dass der Debugging-Prozess eine ziemlich wichtige Position einnahm.

Irgendwann wurde mir klar, dass ich mich einfach unwohl fühlte, und ich versuchte, Freunde für xDebug und PHPstorm zu finden, wenn ich an einem lokalen Projekt arbeitete. Das Problem ist, dass die meisten Dokumentationen und Anleitungen, die ich gefunden habe, implizieren, dass die Person, die sie liest, sich ziemlich gut mit dem Themenbereich auskennt und alles versteht. In meinem Fall war dies nicht der Fall und ich habe 4-5 für mein erstes xDebug-Setup ausgegeben Stunden in 14 Uhr. Es war eine ziemlich harte Moral, ich fühlte mich unendlich dumm. Trotzdem stellte sich heraus, dass alles konfiguriert war!

Ja, es wurde bequemer, lokal, zu Hause, aber bei der Hauptarbeit habe ich die Sites remote ausgeführt, und meistens war ich nicht in der Lage, die Site entweder lokal zu entladen (aufgrund eines schwachen Computers oder eines unbequemen Bereitstellungsprozesses) oder die Servereinstellungen aufgrund von zu beeinflussen Das Hosting machte daher Änderungen "live" und Debugging mit HTML-Kommentaren print_r (bei dieser Arbeit war es "normal", obwohl nicht stolz auf diese Erfahrung).



Vor 3 Monaten bin ich jedoch zu einer kühleren Firma gewechselt und habe angefangen, mich auf ein wirklich ernstes Projekt mit hoher Last einzulassen. Und hier hat sich für mich viel geändert. Die Infrastruktur und der Entwicklungsprozess sind ungefähr wie folgt: Es gibt einen GitLab-Server, jedes Projekt hat ein eigenes Repository, Aufgaben kommen zu Jira, Sie erstellen einen Zweig nach Aufgabennummern, wenn Sie einen Zweig mit CI erstellen, wird bei jedem Push automatisch Ihre eigene Sandbox mit der Site erstellt, an der Sie leise arbeiten setzt den Zweig wieder zusammen. Am Ende der Arbeit, die Sie der Codeüberprüfung geben, gießen Sie den Zweig in den Master.

Bis auf einen ist alles cool, ABER jeder Wiederaufbau eines Zweigs dauert in meinem Fall ungefähr 10 Sekunden. Im Entwicklungsprozess selbst ist dies eine unbedeutende Zeit, da ich bereits die Phase durchlaufen habe, in der ich aufgrund von Unsicherheit und wenig Erfahrung die Funktionsfähigkeit des Codes in fast jeder Zeile überprüfen musste. Als ich jedoch zum Debuggen wechselte, spielten diese 10 Sekunden eine greifbare Rolle. Der Prozess eines solchen Debuggens sah wie folgt aus:

• Fügen Sie 2 Zeilen hinzu
• Pushu Commit
• Ich warte 10 Sekunden
• Überprüfen Sie, was los ist
• Wiederholen

Nach groben Schätzungen hatte eine zusammenführungsbereite Niederlassung ungefähr 20% nützliche Commits und 80% Debug-Commits. Angenommen, ich habe die Arbeit an einem Zweig mit 300 Festschreibungen beendet, von denen 240 im Wesentlichen nur 40 Minuten meiner Arbeitszeit in Anspruch genommen haben (und dies ist nur die Wartezeit für die Montage des Zweigs, ohne Berücksichtigung der Sekunden, die sich zu Minuten addieren, um 2 Zeilen hinzuzufügen und dann löschen).



Irgendwann hatte ich es satt und entschied mich, xDebug so zu konfigurieren, dass der Debugging-Prozess kostengünstiger wird. Leider haben meine derzeitigen Kollegen diese Technologie entweder nicht verwendet (ich warte auf einen Witz über "Ich habe eine coole Firma, in der niemand xDebug verwendet"), oder sie wussten / erinnerten sich nicht, wie sie sich mit der xDebug-IDE in der Filiale anfreunden sollten Ich habe CI aus der Ferne durchlaufen, und da ich noch nie devOps hatte und wie oben erwähnt, ist das Einrichten von etwas für mich ein ziemlich schmerzhafter Prozess. Es führte zu ungefähr 6 Stunden reiner Zeit, so dass es schließlich funktionierte und ich den Prozess verstand. und das wäre bequem genug.

Einrichtungsprozess

Ich werde nicht näher auf die Befestigung von CI, Docker im Allgemeinen und die Montage der Infrastruktur eingehen. Es wird davon ausgegangen, dass dies alles erledigt ist und alles, was übrig bleibt, die Einrichtung Ihrer persönlichen Umgebung ist.

Angenommen, unser Repository hat ungefähr diese Struktur:



Zuerst müssen wir überprüfen, ob xDebug selbst im aktuellen Image enthalten ist. Dazu können Sie phpinfo () verwenden.

Wenn xDebug bereits in der Assembly enthalten ist - in Ordnung, wenn nicht, dann schauen Sie sich diese Quelle an , die mir direkt im Setup selbst geholfen hat. Ich bin jedoch einen etwas anderen Weg gegangen.

Konfigurieren Sie php.ini

Damit am Ende alles funktioniert, sind uns 2 xDebug-Einstellungen wichtig:

• xdebug.remote_enable
• xdebug.remote_host

In der Endmontage des Remote-Zweigs muss remote_enable aktiviert sein, und in remote_host muss die IP Ihres Computers im Netzwerk zugewiesen werden. Lassen Sie uns diese Einstellungen in unseren Build aufnehmen.

Zuerst müssen Sie herausfinden, wo die PHP-Einstellungen gespeichert sind. Sie befinden sich entweder in /usr/local/etc/php/conf.d/php.ini oder die INI-Datei selbst kann anders benannt werden, in meinem Fall / usr / local / etc / php / conf.d / php-settings.ini . Sie können aus den Einstellungen des gesammelten Bildes herausfinden.

Wir erstellen unsere zusätzlichen Einstellungen in unserem Zweig über dieselbe Datei php-settings.ini und platzieren sie in ./build_env/php/php-settings.ini
Wir schreiben 2 der obigen Einstellungen hinein:
xdebug.remote_enable = on
xdebug.remote_host = IP...

Als nächstes müssen wir diese Datei zu den "übergeordneten" Bildeinstellungen hinzufügen. Ich mache dies durch Volumes, indem ich die Zeile zu ./build_env/docker-compose/docker-compose.tmpl hinzufüge:
- ${PROJECT_DIR}/build_env/php/php-settings.ini:/usr/local/etc/php/conf.d/php-settings.ini

So sieht docker-compose.tmpl in meinem Projekt aus:



Wenn Sie das nächste Mal den Zweig erstellen, können Sie überprüfen, ob die neuen Einstellungen über dieselbe phpinfo () gebunden sind . Wenn ja - ausgezeichnet, wenn nicht - haben Sie kein Glück und müssen den gleichen Weg gehen wie beim ersten Mal :(

Anpassen von Zuordnungen in PHPstorm

Als nächstes müssen Sie PHPstorm selbst konfigurieren. Ich habe mich entschieden, DBgp Proxy nicht zu verwenden, um die Zuordnungen nicht jedes Mal im Popup zu konfigurieren. In meinem Fall verwende ich eine Servervorlage, die die erforderlichen Zuordnungen enthält.

Gehen Sie zu Einstellungen / Einstellungen | Sprachen & Frameworks | Php | Server

1. Erstellen Sie eine Servervorlage
2. Name: NIEDERLASSUNG
3. Host: beliebig, es hat keinen Einfluss
4. Port: beliebig, es hat keinen Einfluss
5. Debugger: xDebug
6. Setzen Sie eine Morgendämmerung auf Pfadzuordnungen verwenden
7. Wir legen die entsprechenden Zuordnungen fest. Die funktionierenden lokalen Ordner sollten den Ordnern auf dem Server entsprechen, auf dem sich die gesammelten Zweige befinden. In meinem Fall befinden sich die gesammelten Builds im Ordner / var / www / builds / your_namespace / your_project / your_branch

Wir speichern diese Einstellungen und ändern sie jedes Mal, wenn wir mit einem neuen Zweig arbeiten. Wenn ich heute beispielsweise mit dem Zweig web-2233 arbeite, ändere ich die Zuordnung in / var / www / build / build_path / web-2233

Fügen Sie eine neue Umgebungsvariable hinzu, damit die IDE die Zuordnungen automatisch abruft

Nun ein ziemlich wichtiger und nicht der offensichtlichste Punkt. Wenn wir das Debuggen starten, muss PHPstorm verstehen, welche lokalen Dateien den Dateien auf dem Remote-Server entsprechen. Wenn der Server keine bestimmte Installation angegeben hat, wird ein Popup-Fenster angezeigt, in dem Sie die Pfade manuell zuordnen müssen. Damit PHPstorm sofort Zuordnungen von einem Server mit dem Namen BRANCH übernehmen kann, müssen Sie unserer Assembly die Umgebungsvariable PHP_IDE_CONFIG hinzufügen

Erstellen Sie in ./build_env/docker-compose/docker-compose.tmpl eine neue Umgebungsvariable in der Umgebung:
PHP_IDE_CONFIG: ${PHP_IDE_CONFIG}



In .gitlab-ci.yml setzen wir diese Variable:
- export PHP_IDE_CONFIG="serverName=BRANCH"

Fertig!

Wir benötigen keine Browsererweiterungen, müssen keine URL XDEBUG_SESSION_START = IDE_KEY übergeben, um Parameter abzurufen. Wir müssen keine zusätzlichen Konfigurationen hinzufügen.

Schalten Sie einfach den Abhörschalter ein und aktualisieren Sie die Site-Seite, sobald wir auf den ersten Haltepunkt stoßen, wird die Anwendung darauf gestoppt



Vielen Dank für Ihre Aufmerksamkeit, ich hoffe, dieser Artikel wird nützlich sein und jemand wird Zeit sparen, ohne auf den gleichen Rechen wie ich zu treten :)

Quellen, die ich bei der Ersteinrichtung verwendet habe:
https://gist.github.com/chadrien/c90927ec2d160ffea9c4
https://confluence.jetbrains.com/display/PhpStorm/Docker+Support+in+PhpStorm#DockerSupportinPhpStorm-DebuggingthePHPwebapplicationrunningintheDockercontainer