Comments 19
А могли бы просто написать автотесты и/или гонять их через phpdbg…
Боюсь, что не все так просто. Я понимаю, как следует делать, но когда приходишь на новое место, где работать нужно с тем, что есть — многие нужные штуки не возникают в одночасье. Автотесты и более надежные технологии есть в планах, даже ближайших, однако есть огромное количество ньансов и более важных проблем, которые нужно решить параллельно с требованиями бизнеса.
Чтобы понимать о каких ньансах и проблемах я говорю:
Чтобы понимать о каких ньансах и проблемах я говорю:
- Продакшен имеет версию PHP 5.3, тестовая среда 7.1
- Кодовая база продакшена сильно отличается от мастер ветки
- Продакшен не собирается докером
- В силу специфики проекта и легаси-кода исправление пунктов выше затягиваются
Интересная ситуация, действительно. Думаю, краткое описание этих проблем стоит внести в статью, чтобы у читателей сложилось адекватное представление о нетривиальных условиях раобты.
Строго говоря, это является обычным делом на проектах, начавшихся тогда, когда современные технологии ещё не получили широкого распространения. С нуля переделывать работающий проект при сколь-нибудь имеющемся развитии неправильно, и делается это по мере возможности по частям.
Когда прод 5.3, а тестовая 7.1, то нужно брать гвозди двухсотки и идти забивать их в голову девопсам и тимлидам.
Так нельзя работать и разрабатывать.
В конечном счёте есть Docker, который обещает равное окружение хотя бы на уровне версий пхп.
Я согласен, но отдельного девопса у нас нет, потому что считалось, что раз у других проектов все настроено отлично в плане инфраструктуры, то и наш перенести будет не трудно, но оказалось это не так, сейчас уже почти все готово, но постоянно появляются новые косяки, которые нельзя было решить, пока определенные люди в отпуске или заняты над другими задачами
Если у вас на проде и дев/стейджинге разные окружения, то что и как вы тестируете?
Беда в том, что большинство документаций и гайдов, которые я нашел, подразумевают, что читающий их человек довольно хорошо разбирается в предметной области и все понимает, в моем случае это было не так и на свою первую настройку xDebug я в сумме потратил 4-5 часов за 2 вечера.
Для Хрома есть расширение xDebug helper… С ним даже самый тупой потратит не больше 30 минут.
Я писал о расширении в самом конце статьи. Единственное, что делает это расширение — позволяет не использовать get-параметры в url, а передает информацию самостоятельно, на работу с удаленными проектами это расширение не влияет. В любом случае, инструкция о другом, рад, что у Вас получилось разобраться так быстро
Как в тему мне попало. Спасибо, автор, добавлю в закладки:))
Почему стоит уйти от заплесневевших методов отладки и перейти на адекватные технологии?
Наверное потому, что они работают. И довольно неплохо. ;)
Статья хороша, +
Интересно в какой среде вы работаете Windows или Linux? При работе с git в Linux очень не хватает аналога TortoiseGit. Например в редакторе NetBeans есть хороший клиент для Git в Eclipse худо-бедно можно посмотреть историю, но с ними хорошо, пока все хорошо. Как только не проходят push или pull из-за локальных конфликтов или конфликтов с branch, приходится загружаться под Windows и через TortoiseGit решать проблему.
Прописываем в нем 2 вышеупомянутые настройки:
xdebug.remote_enable = on
xdebug.remote_host = IP.ВАШЕГО.КОМПЬЮТЕРА.ВСЕТИ
Нам не нужны расширения для браузера, не нужно передавать в get-параметры URL XDEBUG_SESSION_START=IDE_KEY, не нужно добавлять дополнительные конфигурации.
Достаточно просто включить прослушку
Недостаточно. Возможно Вы просто забыли скопировать в статью, но для именно такого поведения нужно включить флаг xdebug.remote_autostart в конфигурацию PHP. Иначе xdebug расширение всё ещё будет ждать cookie XDEBUG_SESSION либо query параметр XDEBUG_SESSION_START либо, в случае с CLI, переменную окружения XDEBUG_CONFIG=«idekey=*****»
И не совсем понятно, Вы это проделываете с настройкой docker каждый раз когда прилетает новая задача (новая ветка)? Если да, то советую всё же воспользоваться браузерными плагинами, убрать xdebug.remote_host/port, отключить xdebug.remote_autostart и включить remote_connect_back. Тогда эти настройки можно положить под контроль версий, откуда ими смогут воспользоваться все.
Ну и конечно всё это работает пока вам нужно дебажить только один сервер. Иначе, следующие утверждения неверны:
host: любой, он не влияет
port: любой, он не влияет
Всё вышеописанное работает пока сервер в одной сети с вами, в остальных случаях советую использовать DBGp proxy.
Во первых используя IDE_KEY можно дебажить один и тот же сервер нескольким разработчикам сразу, например общие тестовые сервера. Такое иногда бывает ))
Во вторых можно дебажить «очень» удалённые сервера без пробрасывания портов на каждой рабочей станции. Нужно только одно плечо DBGp сервера выпустить в мир, то которое работает непосредственно с xdebug расширением. Плечё которое работает с IDE можно оставить за NAT-ом. А имея подключение к офисной сети по VPN, спокойно дебажить все нужные сервера даже не будучи в офисе.
И всё это не требует каждый раз настраивать xdebug на стороне сервера. Один общий xdebug.ini где выключены xdebug.remote_autostart и xdebug.remote_connect_back и включено соединение с DBGp прокси сервером.
Пример настройки
Здесь 9900 это как раз то плечё которое смотрит в сторону xdebux расширения. В сторону IDE будет стандартный 9000.
xdebug.remote_connect_back = 0
xdebug.remote_autostart = 0
xdebug.remote_enable = 1
xdebug.remote_handler = "dbgp"
xdebug.remote_host = "YOUR.DBPP.SERVER.ADDR"
xdebug.remote_port = 9900
xdebug.remote_log="/tmp/xdebug.log"Здесь 9900 это как раз то плечё которое смотрит в сторону xdebux расширения. В сторону IDE будет стандартный 9000.
Sign up to leave a comment.
Как подружить PHPstorm, xDebug и удаленные ветки, собранные через Docker? Слишком просто…