¿Cómo hacer amigos PHPstorm, xDebug y ramas remotas compiladas a través de Docker? Demasiado simple ...

Buen dia, Habr!

Hace un año, mi proceso de depuración de código en PHP consistía en dos líneas:

var_dump($variable); die(); 

De vez en cuando, por supuesto, tenía que usar construcciones más "complejas":

 console.log(data); 

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

No, que eres! Lo sabía, en nuestro tiempo no es apropiado que un programador cultural haga esto


Pero honestamente, siempre tuve miedo de lo que no entendía. Incluyendo impresoras xDebug, especialmente cómo configurar todo esto. Un buen día, logré hacerlo en mi automóvil y en un proyecto local: no había límite para la alegría. Muchos meses después, me encontré con un nuevo problema, cómo depurar en PHPstorm a través de xDebug, si el proyecto está construido de forma remota por Docker a través de CI.

Si, como yo, tiene dificultades para configurar diferentes cosas, bienvenido a la escena, le contaré sobre mi experiencia en la configuración de un entorno de depuración con palabras aterradoras como Docker, xDebug, CI.

Para aquellos que no les gusta el agua y quieren ir directamente a la esencia del entorno.

¿Por qué debería alejarse de los métodos de depuración con moho y cambiar a tecnologías adecuadas?

Engañé un poco al gato, me dediqué a la depuración artesanal, no solo porque tenía miedo de configurar algo, y no porque fuera demasiado estúpido, sino simplemente porque no necesitaba algo más conveniente. Muy a menudo, trabajaba en proyectos localmente en mi computadora bastante poderosa, y las tareas no eran tan complicadas que el proceso de depuración comenzó a ocupar una posición bastante significativa.

En algún momento, me di cuenta de que estaba incómodo e intenté hacer amigos xDebug y PHPstorm cuando trabajaba en un proyecto local. El problema es que la mayoría de la documentación y las guías que encontré implican que la persona que las lee tiene bastante conocimiento del área temática y entiende todo, en mi caso este no fue el caso y pasé 4-5 en mi primera configuración de xDebug horas en 2 pm. Fue una moral bastante dura, me sentí infinitamente tonto. Sin embargo, resultó configurar, ¡todo funcionó!

Sí, se volvió más conveniente, localmente, en casa, pero en el trabajo principal hice los sitios de forma remota, y la mayoría de las veces no pude descargar el sitio localmente (debido a una máquina débil o un proceso de implementación inconveniente), o afectar la configuración del servidor debido a hosting, por lo tanto, realizó ediciones "en vivo" y depuró a través de html-commenting print_r (en ese trabajo fue "normal", aunque no orgulloso de esta experiencia).



Sin embargo, hace 3 meses me mudé a una empresa más fresca y comencé a participar en un proyecto realmente serio con una gran carga. Y aquí muchas cosas han cambiado para mí. La infraestructura y el proceso de desarrollo son aproximadamente los siguientes: hay un servidor GitLab, cada proyecto tiene su propio repositorio, las tareas llegan a Jira, se crea una rama por números de tarea, al crear una rama usando CI, se crea automáticamente su propia caja de arena con el sitio donde trabaja en silencio, cada inserción vuelve a ensamblar la rama, al final del trabajo que le da a la revisión del código, vierta la rama en el maestro.

Todo está bien, excepto un PERO, cada reconstrucción de una rama en mi caso lleva unos 10 segundos. En el proceso de desarrollo en sí, este es un momento insignificante, ya que ya pasé la etapa en la que tuve que verificar la operabilidad del código en casi todas las líneas debido a la incertidumbre y la poca experiencia. Sin embargo, cuando cambié a la depuración, estos 10 segundos comenzaron a jugar un papel tangible. El proceso de dicha depuración fue el siguiente:

• Agregar 2 líneas
• Pushu commit
• Espero 10 segundos
• Mira, mira qué pasa
• Repetir

Según estimaciones aproximadas, una rama lista para fusionar tenía aproximadamente un 20% de confirmaciones útiles y un 80% de confirmaciones de depuración. Supongamos que terminé de trabajar en una rama con 300 confirmaciones, de las cuales 240 confirmaciones consumieron esencialmente 40 minutos de mi tiempo de trabajo (y este es solo el tiempo de espera para el ensamblaje de la rama, sin tener en cuenta los segundos que suman hasta minutos, para agregar 2 líneas y luego eliminarlos).



En algún momento estaba cansado y decidí configurar xDebug para que el proceso de depuración fuera menos costoso. Desafortunadamente, mis colegas actuales no usaron esta tecnología (estoy esperando una broma sobre "Tengo una compañía genial donde nadie usa xDebug"), o no sabían / ​​no recordaban cómo hacer amigos con el IDE de xDebug cuando la sucursal yendo de forma remota a través de CI, y como nunca he desarrollado y, como mencioné anteriormente, el proceso de configuración es un proceso doloroso para mí, me llevó aproximadamente 6 horas de tiempo puro para finalmente trabajar, y entendí el proceso, y eso sería lo suficientemente conveniente.

Proceso de configuración

No entraré en detalles sobre cómo sujetar CI, Docker, en general, cómo ensamblar la infraestructura, se supone que todo está hecho y todo lo que queda es configurar su entorno personal.

Digamos que nuestro repositorio tiene algo como esta estructura:



Primero debemos verificar si xDebug está en la imagen actual, para esto puedes usar phpinfo ();

Si xDebug ya está incluido en el ensamblaje, está bien, si no, entonces revise esta fuente , que me ayudó directamente en la configuración en sí, sin embargo, tomé un camino un poco diferente.

Configurar php.ini

Para que todo funcione al final, 2 configuraciones de xDebug son importantes para nosotros:

• xdebug.remote_enable
• xdebug.remote_host

En el ensamblaje final de la rama remota, remote_enable debe estar habilitado y en remote_host debe asignarse la IP de su computadora en la red. Incluyamos esta configuración en nuestra compilación.

Primero debe averiguar dónde se almacenan las configuraciones de php, pueden ubicarse en /usr/local/etc/php/conf.d/php.ini , o el archivo .ini en sí mismo puede tener un nombre diferente, en mi caso es / usr / local / etc / php / conf.d / php-settings.ini . Puede averiguarlo desde la configuración de la imagen recopilada.

Creamos nuestra configuración adicional en nuestra sucursal a través del mismo archivo php-settings.ini y la colocamos en ./build_env/php/php-settings.ini
Escribimos en él 2 de las configuraciones anteriores:
xdebug.remote_enable = on
xdebug.remote_host = IP...

A continuación, debemos agregar este archivo a la configuración de imagen "principal". Hago esto a través de volúmenes agregando la línea a ./build_env/docker-compose/docker-compose.tmpl:
- ${PROJECT_DIR}/build_env/php/php-settings.ini:/usr/local/etc/php/conf.d/php-settings.ini

Así es como se ve docker-compose.tmpl en mi proyecto:



La próxima vez que construya la rama, puede verificar si la nueva configuración está vinculada a través del mismo phpinfo (); en caso afirmativo, excelente, si no, no tiene suerte y tendrá que seguir el mismo camino que hice la primera vez :(

Personalización de asignaciones en PHPstorm

A continuación, debe configurar PHPstorm. Decidí no usar DBgp Proxy, para no configurar las asignaciones en la ventana emergente cada vez. En mi caso, uso una plantilla de servidor que contendrá las asignaciones necesarias.

Vaya a Configuración / Preferencias | Idiomas y marcos | Php | Servidores

1. Crear una plantilla de servidor
2. Nombre: RAMA
3. host: cualquiera, no afecta
4. puerto: cualquiera, no afecta
5. Depurador: xDebug
6. Da un toque en Usar asignaciones de ruta
7. Colocamos las asignaciones apropiadas, las carpetas locales de trabajo deben corresponder a las carpetas en el servidor donde se encuentran las ramas recopiladas, en mi caso, las compilaciones recopiladas están en la carpeta / var / www / builds / your_namespace / your_project / your_branch

Guardamos estas configuraciones, las cambiaremos cada vez que trabajemos con una nueva sucursal. Por ejemplo, si hoy trabajo con la rama web-2233, entonces cambiaré la asignación a / var / www / builds / build_path / web-2233

Agregue una nueva variable de entorno para que el IDE extraiga automáticamente las asignaciones

Ahora un punto bastante importante y no el más obvio. Cuando comenzamos la depuración, PHPstorm necesita comprender qué archivos locales corresponden a los archivos en el servidor remoto. Si el servidor no le proporcionó una instalación específica, aparecerá una ventana emergente en la que deberá asignar manualmente las rutas. Para que PHPstorm tome asignaciones inmediatamente de un servidor con el nombre BRANCH, debe agregar la variable de entorno PHP_IDE_CONFIG a nuestro ensamblado

En ./build_env/docker-compose/docker-compose.tmpl cree una nueva variable de entorno en el entorno:
PHP_IDE_CONFIG: ${PHP_IDE_CONFIG}



En .gitlab-ci.yml establecemos esta variable:
- export PHP_IDE_CONFIG="serverName=BRANCH"

Hecho

No necesitamos extensiones del navegador, no necesitamos pasar URL XDEBUG_SESSION_START = IDE_KEY para obtener parámetros, no necesitamos agregar configuraciones adicionales.

Solo enciende la escucha y actualice la página del sitio, tan pronto como nos topemos con el primer punto de interrupción, la aplicación se detendrá



Gracias por su atención, espero que este artículo sea útil y alguien ahorre tiempo sin pisar el mismo rastrillo que yo :)

Fuentes que utilicé durante la configuración inicial:
https://gist.github.com/chadrien/c90927ec2d160ffea9c4
https://confluence.jetbrains.com/display/PhpStorm/Docker+Support+in+PhpStorm#DockerSupportinPhpStorm-DebuggingthePHPwebapplicationrunningintheDockercontainer