Comment se faire des amis PHPstorm, xDebug et les branches distantes compilées via Docker? Trop simple ...

Bonjour, Habr!

Il y a un an, mon processus de débogage de code en PHP comprenait deux lignes:

var_dump($variable); die(); 

De temps en temps, bien sûr, je devais utiliser des constructions plus "complexes":

 console.log(data); 

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

Non, tu es quoi! Je savais - à notre époque, ce n'est pas approprié pour un programmeur culturel de faire ça


Mais honnêtement, j'avais toujours peur de ce que je ne comprenais pas. Y compris les imprimantes xDebug, en particulier comment configurer tout cela. Un beau jour, j'ai réussi à le faire dans ma voiture et dans un projet local - il n'y avait pas de limite à la joie. Plusieurs mois plus tard, je suis tombé sur un nouveau problème, comment déboguer dans PHPstorm via xDebug, si le projet est construit à distance par docker via CI.

Si vous, comme moi, avez des difficultés à configurer différentes choses, bienvenue au chat, je parlerai de mon expérience dans la mise en place d'un environnement de débogage avec des mots effrayants comme Docker, xDebug, CI.

Pour ceux qui n'aiment pas l'eau et veulent aller directement à l'essence du décor.

Pourquoi devriez-vous vous éloigner des méthodes de débogage moisies et passer à des technologies adéquates?

J'ai un peu trompé le chat, j'étais engagé dans un débogage artisanal, non seulement parce que j'avais peur de configurer quelque chose, et non pas parce que c'était trop stupide, mais simplement parce que je n'avais pas besoin de quelque chose de plus pratique. Le plus souvent, j'ai travaillé sur des projets localement sur mon ordinateur plutôt puissant, et les tâches n'étaient pas si compliquées que le processus de débogage a commencé à occuper une position assez importante.

À un moment donné, je me suis rendu compte que j'étais mal à l'aise et j'ai essayé de me faire des amis xDebug et PHPstorm lorsque je travaillais sur un projet local. Le problème est que la plupart de la documentation et des guides que j'ai trouvés impliquent que la personne qui les lit connaît assez bien le domaine et comprend tout, dans mon cas, ce n'était pas le cas et j'ai dépensé 4-5 sur ma première configuration de xDebug heures à 14 h. C'était une morale assez difficile, je me sentais infiniment stupide. Néanmoins, il s'est avéré qu'il fallait configurer, tout fonctionnait!

Oui, cela est devenu plus pratique, localement, à la maison, mais au travail principal, j'ai fait les sites à distance, et le plus souvent, je n'ai pas pu décharger le site localement (en raison d'une machine faible ou d'un processus de déploiement peu pratique), ou affecter les paramètres du serveur en raison de l'hébergement, par conséquent, a fait des modifications "en direct" et le débogage s'est engagé dans print_r commentant html (à ce travail, c'était "normal", mais pas fier de cette expérience).



Cependant, il y a 3 mois, j'ai déménagé dans une entreprise plus cool et j'ai commencé à me lancer dans un projet vraiment sérieux avec une charge élevée. Et ici, beaucoup de choses ont changé pour moi. L'infrastructure et le processus de développement sont approximativement les suivants: il y a un serveur GitLab, chaque projet a son propre référentiel, les tâches viennent à Jira, vous créez une branche par numéros de tâche, lors de la création d'une branche à l'aide de CI, votre propre sandbox avec le site où vous travaillez tranquillement est automatiquement créé, chaque push réassemble la branche, à la fin du travail que vous lui donnez à la revue de code, versez la branche dans le maître.

Tout est cool sauf pour un MAIS, chaque reconstruction d'une branche dans mon cas prend environ 10 secondes. Dans le processus de développement lui-même, c'est une période insignifiante, car j'ai déjà franchi le stade où je devais vérifier l'opérabilité du code presque toutes les lignes en raison de l'incertitude et du peu d'expérience. Cependant, lorsque je suis passé au débogage, ces 10 secondes ont commencé à jouer un rôle tangible. Le processus d'un tel débogage se présente comme suit:

• Ajouter 2 lignes
• Pushu commit
• J'attends 10 secondes
• Vérifiez, voyez ce qui ne va pas
• Répéter

Selon des estimations approximatives, une branche prête pour la fusion avait environ 20% de validations utiles et 80% de validations de débogage. Supposons que j'ai fini de travailler sur une branche avec 300 validations, dont 240 validations ont essentiellement consommé 40 minutes de mon temps de travail (et ce n'est que le temps d'attente pour l'assemblage de la branche, sans prendre en compte les secondes qui totalisent les minutes, pour ajouter 2 lignes puis supprimez-les).



À un moment donné, j'en ai eu assez et j'ai décidé de configurer xDebug pour rendre le processus de débogage moins coûteux. Malheureusement, mes collègues actuels n'ont pas utilisé cette technologie (j'attends une blague sur "J'ai une entreprise sympa où personne n'utilise xDebug"), ou ils ne savaient pas / ne se souvenaient pas comment se faire des amis avec l'IDE xDebug lorsque la branche aller à distance via CI, et comme je n'ai jamais développé et comme je l'ai mentionné ci-dessus, le processus de mise en place de quelque chose est un processus assez pénible pour moi, il a résulté en environ 6 heures de temps pur, donc finalement cela a fonctionné, et j'ai compris le processus, et ce serait assez pratique.

Processus d'installation

Je n'entrerai pas dans les détails sur la façon de fixer CI, Docker, en général, comment assembler l'infrastructure, il est supposé que tout est fait et qu'il ne reste plus qu'à configurer votre environnement personnel.

Disons que notre référentiel a quelque chose comme cette structure:



Nous devons d'abord vérifier si xDebug lui-même est dans l'image actuelle, pour cela, vous pouvez utiliser phpinfo ();

Si xDebug est déjà inclus dans l'assembly - très bien, sinon, consultez cette source , qui m'a aidé directement dans la configuration elle-même, cependant, je suis allé un peu différemment.

Configurer php.ini

Pour que tout fonctionne à la fin, 2 paramètres xDebug sont importants pour nous:

• xdebug.remote_enable
• xdebug.remote_host

Dans l'assemblage final de la branche distante, remote_enable doit être activé et dans remote_host, l' adresse IP de votre ordinateur sur le réseau doit être attribuée. Incluons ces paramètres dans notre build.

Vous devez d'abord savoir où les paramètres php sont stockés, ils peuvent être situés dans /usr/local/etc/php/conf.d/php.ini , ou le fichier .ini lui-même peut être nommé différemment, dans mon cas, il s'agit de / usr / local / etc / php / conf.d / php-settings.ini . Vous pouvez le découvrir dans les paramètres de l'image collectée.

Nous créons nos paramètres supplémentaires dans notre branche via le même fichier php-settings.ini et les plaçons dans ./build_env/php/php-settings.ini
Nous y écrivons 2 des paramètres ci-dessus:
xdebug.remote_enable = on
xdebug.remote_host = IP...

Ensuite, nous devons ajouter ce fichier aux paramètres d'image "parent". Je fais cela à travers les volumes en ajoutant la ligne à ./build_env/docker-compose/docker-compose.tmpl:
- ${PROJECT_DIR}/build_env/php/php-settings.ini:/usr/local/etc/php/conf.d/php-settings.ini

Voici à quoi ressemble docker-compose.tmpl dans mon projet:



La prochaine fois que vous construirez la branche, vous pourrez vérifier si les nouveaux paramètres sont liés via le même phpinfo (); si oui - excellent, sinon - vous n'avez pas de chance et vous devrez suivre la même voie que la première fois :(

Personnalisation des mappages dans PHPstorm

Ensuite, vous devez configurer PHPstorm lui-même. J'ai décidé de ne pas utiliser le proxy DBgp, afin de ne pas configurer les mappages dans le popup à chaque fois. Dans mon cas, j'utilise un modèle de serveur qui contiendra les mappages nécessaires.

Allez dans Paramètres / Préférences | Langues et cadres | Php | Serveurs

1. Créer un modèle de serveur
2. Nom: BRANCH
3. hôte: tout, cela n'affecte pas
4. port: tout, il n'affecte pas
5. Débogueur: xDebug
6. Mettez un point sur l'utilisation des mappages de chemin
7. Nous posons les mappages appropriés, les dossiers locaux de travail doivent correspondre aux dossiers sur le serveur où se trouvent les branches collectées, dans mon cas les builds collectés sont dans le dossier / var / www / builds / your_namespace / your_project / your_branch

Nous enregistrons ces paramètres, nous les changerons chaque fois que nous travaillerons avec une nouvelle branche. Par exemple, si aujourd'hui je travaille avec la branche web-2233, je changerai le mappage en / var / www / builds / build_path / web-2233

Ajoutez une nouvelle variable d'environnement pour que l'EDI récupère automatiquement les mappages

Maintenant un point assez important et pas le plus évident. Lorsque nous démarrons le débogage, PHPstorm doit comprendre quels fichiers locaux correspondent aux fichiers sur le serveur distant. Si le serveur ne lui a pas donné d'installation spécifique, une fenêtre contextuelle apparaîtra dans laquelle vous devrez mapper manuellement les chemins. Pour que PHPstorm prenne immédiatement les mappages d'un serveur portant le nom BRANCH, vous devez ajouter la variable d'environnement PHP_IDE_CONFIG à notre assembly

Dans ./build_env/docker-compose/docker-compose.tmpl, créez une nouvelle variable d'environnement dans l'environnement:
PHP_IDE_CONFIG: ${PHP_IDE_CONFIG}



Dans .gitlab-ci.yml, nous définissons cette variable:
- export PHP_IDE_CONFIG="serverName=BRANCH"

C'est fait!

Nous n'avons pas besoin d'extensions de navigateur, nous n'avons pas besoin de passer l'URL XDEBUG_SESSION_START = IDE_KEY pour obtenir les paramètres, nous n'avons pas besoin d'ajouter de configurations supplémentaires.

Allumez simplement l'écoute électronique et rafraîchir la page du site, dès que nous tomberons sur le premier point d'arrêt, l'application s'arrêtera dessus



Merci de votre attention, j'espère que cet article vous sera utile et que quelqu'un gagnera du temps sans marcher sur le même râteau que moi :)

Sources que j'ai utilisées lors de la configuration initiale:
https://gist.github.com/chadrien/c90927ec2d160ffea9c4
https://confluence.jetbrains.com/display/PhpStorm/Docker+Support+in+PhpStorm#DockerSupportinPhpStorm-DebuggingthePHPwebapplicationrunningintheDockercontainer