How to make PHPstorm, xDebug and remote branches compiled via Docker? Too simple

Kind time of the day, Habr!
A year ago my process of debugging code in PHP consisted of two lines:
var_dump ($ variable);
die ();

Periodically, of course, we had to use more "complex" designs:
console.log (data);

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

No, you! I knew - in our time it does not fit for a cultural programmer to deal with this
ancient craft [/b]
joke about another ancient craft
But, frankly, I was always afraid of what I do not understand. Including printers xDebug, in particular, how to set up this whole thing. One day I managed to do it on my car and in the local project - there was no limit to the joy. After many months, I encountered a new problem, how to debug in PHPstorm via xDebug, if the project is going to be remotely docked via CI.
If you, like me, have difficulty configuring different pieces, welcome under the cut, I'll talk about my experience setting up the debugging environment with such terrible words as Docker, xDebug, CI.
For those who do not like water and want to go directly to the essence of the setting.


Why is it worth moving away from the moldy methods of debugging and switching to adequate technologies?

Above the kat I did a little slukavil, I was engaged in artisanal debugging, not only because I was afraid to adjust anything, and not because it was too stupid, but simply because I did not need something more convenient. Most often I worked on projects locally on my rather powerful computer, and the tasks were not so complicated that the debugging process began to occupy a sufficiently weighty position.
At some point, I realized for myself that I was just uncomfortable, and tried to make xDebug and PHPstorm friends when working on a local project. The trouble is that most of the documentation and guides that I found imply that the person reading them is quite knowledgeable in the subject area and understands everything, in my case it was not so and on my first setup xDebug I spent 4-5 in total hours for 2 pm. It was pretty hard morally, I felt infinitely stupid. Nevertheless, it turned out that everything worked!
Yes, it became more convenient, locally-home, but on the main job I dealt with sites remotely, and more often I did not have the option either to unload the site locally (due to a weak machine or inconvenient deployment process), or to affect server settings due to Hosting, therefore, made edits "live" and debugged through html-commenting print_r (at that job it was "normal", although I'm not proud of this experience).
How to make PHPstorm, xDebug and remote branches compiled via Docker? Too simple
However, 3 months ago I moved to a cooler company and began to engage in a really serious project with a high load. And here a lot has changed for me. The infrastructure and development process are roughly the same: there is a GitLab server, each project has its own repository, Jira comes with tasks, you create a branch by task numbers, when creating a branch using CI, you automatically create your own sandbox with the site where you work quietly, each push rebuilds the branch, at the end of the work you give it to the code-review, you pour the branch into the master.
All is cool except for one BUT, each rebuilding the branch in my case takes about 10 seconds. In the process of the development itself, this is an insignificant time, since I have already passed the stage when I had to check the code for almost every line because of uncertainty and small experience. However, when I switched to debugging, these 10 seconds began to play a significant role. The process of such debugging looked like this:
I add 2 lines of
Push commit
I'm waiting for 10 seconds
I check, I look, that not so
According to rough estimates, the ready-to-merge branch had approximately 20% of useful commits and 80% of commit debugging. For example, I ended up working on a branch with 300 commits, of which 240 commits basically simply otzhirali 40 minutes of my working time (and this is just waiting for the assembly of the branch, not considering those seconds that add up in minutes, to add 2 lines and then delete them).

At some point, I was sick of it and I decided to set up xDebug, so that the debugging process became less expensive. Unfortunately, my current colleagues either did not use this technology (I'm waiting for a joke about "I got a job in a cool company where nobody uses xDebug"), or they did not know how to make IDE friends with xDebug, in case the branch is going to be remotely through CI, and since I have never devOps and as I mentioned above, the setup process for something is a rather painful process for me, it resulted in about 6 hours of clean time, finally it all worked, and I understood the process, and this it would be convenient enough.
this source is , which helped me directly in the setup itself, however I went a little along a different path.

Configure php.ini

In order to make everything work, we need 2 xDebug settings:
In the final assembly of the remote branch remote_enable should be included, but in remote_host must be assigned to the IP of your computer on the network. Let's include these settings in our build.
First you need to find out where the php settings are stored, they can be located either in /usr/local/etc/php/conf.d/php.ini , or the .ini file itself can be named differently, in my case it's /usr/local/etc/php/conf.d/php-settings.ini . You can learn this from the settings of the image you are collecting.
Create in our branch your additional settings through the same php-settings.ini file, and place it in ./build_env/php/php-settings.ini
We prescribe in it the two above settings:
xdebug.remote_enable = on
xdebug.remote_host = IP.Your .computer.VISET

Next, we need to add this file to the "parent" image settings. I do this through volumes by adding the line:
to the ./build_env/docker-compose/docker-compose.tmpl line.  
- $ {PROJECT_DIR} /build_env/php/php-settings.ini:/usr/local/etc/php/conf.d/php-settings.ini
Approximately so in the end looks docker-compose.tmpl in my project:

At the next branch assembly, you can check whether the new settings are tied to the same phpinfo (); , if yes - excellent, if not - you are unlucky and will have to go the same way that I did the first time: (

Set up the mappings in PHPstorm

Next, you need to configure the PHPstorm itself. I decided not to use DBgp Proxy to not configure the Mapping in a pop-up window every time. In my case, I'm using a server template that will contain the necessary mappings.
We pass to Settings /Preferences | Languages ​​& Frameworks | PHP | Servers
  2. Create the server template  
  3. Name: BRANCH  
  4. host: any, it does not affect  
  5. port: any, it does not affect  
  6. Debugger: xDebug  
  7. We put a daw on Use path mappings  
  8. We put the appropriate mappings, the working local folders should correspond to the folders on the server where the collected branches are located, in my case the assembled builds are in the folder /var /www /builds /your_namespace /your_project /your_branch  


We keep these settings, we will change them every time we work with a new branch. For example, if today I'm working with the web-2233 branch, I'll change the mapping to /var /www /builds /path_to_bild /web-2233

We add a new environment variable, so that the IDE automatically tightens the mappings

Now a rather important and not the most obvious moment. When we start debugging, PHPstorm should understand which local files correspond to the files on the remote server. If the server did not give it a specific installation, then a pop-up window will appear, in which it is necessary to put the correspondence paths manually. In order that PHPstorm immediately take the mapping from the server called BRANCH, you need to add the environment variable to our assembly. PHP_IDE_CONFIG
In ./build_env/docker-compose/docker-compose.tmpl create a new environment variable in the environment:

In .gitlab-ci.yml set this variable:
- export PHP_IDE_CONFIG = "serverName = BRANCH"



We do not need browser extensions, you do not need to pass in the get-parameters URL XDEBUG_SESSION_START = IDE_KEY, you do not need to add additional configurations.
It's enough just to turn on the bug and update the page of the site, as soon as we stumble on the first breakpoint, the application will stop running on it

Thank you for attention, I hope this article will be useful and someone will save time, without stepping on the same rake as I :)
Sources that I used for the initial setup:
+ 0 -

Add comment