Спасибо за статью, присматриваюсь краем глаза к этой теме, а тут вот. Сразу полез в пример для нетерпеливых и вдруг не обнаружил trace'а запросов между браузером и сервером. Я в WebSoсket'ах не копенгаген, но при разработке web-приложений мне очень полезна бывает информация о том, что за данные ходят между клиентом и сервером, ходят ли вообще, а если ходят, то как выглядят.
Увидел ничего, испугался и полез для проверки на www.websocket.org/echo.html — там меня успокоили тем, что trace обнаружился. В связи с чем вопрос — простое демо работает, как и задумывалось или не совсем? Потому что ответ «I'm delayed 2 seconds» я получаю, а вот в логах этого не вижу. Раз в минуту браузер отправляет запрос на сервер:
Нашел в интернетах, как создавать собственные пакеты с Magento Core — github.com/WeareJH/magento-skeleton/wiki/Creating-a-Core-Package Т.е., если нужно разворачивать свой модуль на EE-платформе, то создается соответствующий модуль, который и используется вместо
Я об этом не знал, поэтому до сих пор разрабатываю модули на рабочей станции под Win7 :) Да и последний production-сервер под Windows мы убрали буквально пару месяцев назад — мигрировали на linux'овый. Версия 1.9.0.1 CE вполне добротно стояла под wind'ой. Посмотрел системные требования — действительно, минимум с ноября 2013 года указана платформа Linux x86, x86-64. Ну мы, по крайней мере, не сталкивались с проблемами, вызванными тем, что Magento была развернута в win-среде. Там разворачивались одни из первых наших проектов (2-3 года назад), потом начали разворачивать на linux-серверах. Хотя разработка, как я уже отметил, идет на рабочих станциях под Windows.
Как минимум, Magento Composer предполагает возможность развертывания под Windows, в то время, как modman сообщает:
Windows (including cygwin) is not supported by this script, but there is a PHP-port of modman which works on Windows. I am not affiliated with the authors and do not provide support for the PHP port, only a link here for reference.
Плюс, сам Composer является более универсальным инструментом (уровень PHP-сообщества), чем modman (уровень Magento-сообщества). Эти два пункта и побудили нас рассматривать Magento Composer вместо modman'а.
К сожалению, с чистым modman'ом не работали. На данный момент мы разворачиваемся из SVN'а с использованием самописных shell-скриптов, монтируя узлы репозитория в дерево Magento-приложения на уровне каталогов.
Прошу прощения за задержку с ответом — Новый Год и все такое…
На данный момент мы только рассматриваем возможность перехода на использование Magento Composer для развертывания наших проектов. Поэтому я не могу сказать, насколько удачно выбранное решение — нет опыта использования по полному циклу, от создания проекта, до его развертывания и внесения изменений. Что же касается предполагаемой структуры репозитория, то ее можно увидеть на github'е:
Деплой на CE платформу описан в статье, к сожалению по поводу ЕЕ ничего не могу сказать — мы просто не сталкивались с таким вариантом. Похоже, что в репозитории нет такого модуля.
По поводу развертывания проекта для различных задач (у нас это 4 варианта: девелоперская, тестовая, пилотная и production) я планирую написать отдельную статью. Когда доберусь до этого вопроса и разберусь в нем. Если доберусь и разберусь. Пока что только понятно, что стратегия развертывания для production-версии должна быть copy, а не symlink — т.е., там должен быть очень сильно другой composer.json.
В тексте по ссылке говорится, что PhpStorm не поддерживает команд Git'а по работе с сабмодулями в одном проекте...
Или я неправильно понял?
Я вижу, что на данный момент PhpStorm позволяет коммитить в разные репозитории изменения за один подход и обновлять их. Насколько я понял MetalGuardian, это фича самого PhpStorm'а, не зависящая от git'а. Т.е., этот функционал обеспечивается PhpStrom'ом без использования функционала git submodules. Разве нет?
Спасибо за развернутый ответ. Для сборки prodcton-версии проекта я смотрю в сторону PHP Composer, сборку девелоперской версии без монтирования в проект исходников всех зависимых модулей, участвующих в разработке, я пока не представляю. Допустим, я могу отказаться от субмодулей gt'а, Но от монтирования в девелоперскую версию модулей, находящихся в различных репоизиториях (как того ожидает тот же composer) я уж точно не смогу отказаться. Это сильно затормозит (да что у ж там — остановит) проекты в которых я участвую — разработка e-commerce приложений на базе Magento. Я не представляю, каким образом эмулировать Magento для разработки Magento-модуля в «чистой среде», а особенно, когда у меня есть код, общий для всех наших проектов, и специализация кода под конкретный проект. А это минимум два модуля, которые должны девелопиться параллельно. А потом до общего модуля «докручивается» функционал специализированных модулей и в других проектах.
ОК, вынес важную для себя мысль — сабмодули у народа не в подчете. Буду ступать осторожнее :)
А у нас архитектура такая — есть модуль, в котором лежит функционал для всех наших проектов (задает поведение), есть модуль в котором идет реализация поведения для связанной группы проектов, есть модуль специализирующий поведение для конкретного проекта. И если я реализую базовую функцию, то я могу вносить изменения одновременно во все три модуля.
Если с сабмодулями не хорошо, то что в них плохого? По мне — так это просто нативный способ компоновать единый проект из разных репозиториев. То, что я в SVN делал при помощи sh/cmd-скриптов теперь могу делать нативно на уровне git'а. Насколько хорошо — другой вопрос. Но в чем зло? Или вы рекомендуете использовать старые-добрые shell-скрипты для монтирования проекта?
В тексте по ссылке говорится, что PhpStorm не поддерживает команд Git'а по работе с сабмодулями в одном проекте, но вот опыт MetalGuardian говорит о том, что PhpStorm и без этого неплохо справляется.
Чем плохи сабмодули? И как переходить на «версионированные бинарные зависимости» (и что то есть для PHP?), если для решения какого-либо таска мне нужно править исходный код сразу двух-трех модулей в рабочем окружении? Ну, допустим, я целевую систему соберу из «бинарников», а разрабатывать как?
Ну и если сабмодули реальное зло, то "storm и без сабмодулей адекватно работает с несколькими репозиториями в одном проекте" (с) :)
У нас есть core-модули, которые участвуют в нескольких наших проектах, поэтому все изменения мы протаскиваем через SVN. Есть система скриптов, которая позволяет монтировать из SVN наши модули в структуру Magento-сервера, а также коммитить все изменения во всех модулях и обновлять их. Монтирование происходит на уровне каталогов, не файлов — SVN этого не позволяет.
При рассмотрении альтернативных средств развертывания пришли к modeman и Magento Composer. modeman вообще не работает с windows, а Magento Composer требует донастройки прав пользователя для своей работы. Поэтому вполне логично появилась мысль мигрировать на linux. Лишней машины у меня нет, да и переключаться между двумя наборами клавиатур/мышек не комфортно, а виртуальных linux-серверов (именно серверов, а не десктопных рабочих станций) — штук 5. Поэтому и родилась идея запустить phpStorm на удаленном сервере с доступом с wind'ы. Чтобы можно было в linux-среде изучить возможности развертывания через Magento Composer (hardlinks!!!) без разрушения основной рабочей среды (Windows) и не создавать при этом новых инсталляций.
Этот пост родился в силу того, что я только в одном месте нашел указание на последовательность действий при запуске x-приложений на linux-машине с доступом к ним с windows-машин через Xming. Если бы я сразу вышел вот на эту страницу, я бы и написал этот пост, но так как я потратил довольно много времени на «плутание в трех соснах», да и чтобы закрепить результат, я написал пост в Хабр (хотя мог и в корпоративную вики).
Кстати, так можно и не только PhpStorm запускать, но и другие x-приложения с удаленной машины. И я использовал PhpStorm как локально (из офиса), так и удаленно (из дома) — вполне рабочее решение. Особого дискомфорта я не испытал, правда у нас интернет довольно хороший. Посмотрю еще VirtualBox, если получится разобраться с ним и развернуть рабочую среду за пару-тройку часов.
Вот в том-то и проблема, что файлы лежат на Windows-машине, а windows не поддерживает hardlinks в полной мере. Система развертывания модулей для Magento modman, например, под windows не работает. Поэтому одним из ограничений является, что файлы должны лежать на linux-машине.
Я разрабатываю под Magento — там очень много файлов в проекте. Не всякая IDE потянет. Например, Zend Studio в свое время не мог прочитать полностью проект со сторонними модулями из-за кольцевого наследования в каких-то классах. Я часто использую поиск по всем файлам проекта и опасаюсь, что sftp-шная папка будет меня сильно тормозить. Хотелось запускать IDE локально.
Увидел ничего, испугался и полез для проверки на www.websocket.org/echo.html — там меня успокоили тем, что trace обнаружился. В связи с чем вопрос — простое демо работает, как и задумывалось или не совсем? Потому что ответ «I'm delayed 2 seconds» я получаю, а вот в логах этого не вижу. Раз в минуту браузер отправляет запрос на сервер:
и получает ответ:
И так — каждую минуту. Похоже, пример не рабочий.
Плюс, сам Composer является более универсальным инструментом (уровень PHP-сообщества), чем modman (уровень Magento-сообщества). Эти два пункта и побудили нас рассматривать Magento Composer вместо modman'а.
На данный момент мы только рассматриваем возможность перехода на использование Magento Composer для развертывания наших проектов. Поэтому я не могу сказать, насколько удачно выбранное решение — нет опыта использования по полному циклу, от создания проекта, до его развертывания и внесения изменений. Что же касается предполагаемой структуры репозитория, то ее можно увидеть на github'е:
Деплой на CE платформу описан в статье, к сожалению по поводу ЕЕ ничего не могу сказать — мы просто не сталкивались с таким вариантом. Похоже, что в репозитории нет такого модуля.
По поводу развертывания проекта для различных задач (у нас это 4 варианта: девелоперская, тестовая, пилотная и production) я планирую написать отдельную статью. Когда доберусь до этого вопроса и разберусь в нем. Если доберусь и разберусь. Пока что только понятно, что стратегия развертывания для production-версии должна быть copy, а не symlink — т.е., там должен быть очень сильно другой composer.json.
Или я неправильно понял?
Я вижу, что на данный момент PhpStorm позволяет коммитить в разные репозитории изменения за один подход и обновлять их. Насколько я понял MetalGuardian, это фича самого PhpStorm'а, не зависящая от git'а. Т.е., этот функционал обеспечивается PhpStrom'ом без использования функционала git submodules. Разве нет?
ОК, вынес важную для себя мысль — сабмодули у народа не в подчете. Буду ступать осторожнее :)
В тексте по ссылке говорится, что PhpStorm не поддерживает команд Git'а по работе с сабмодулями в одном проекте, но вот опыт MetalGuardian говорит о том, что PhpStorm и без этого неплохо справляется.
Ну и если сабмодули реальное зло, то "storm и без сабмодулей адекватно работает с несколькими репозиториями в одном проекте" (с) :)
При рассмотрении альтернативных средств развертывания пришли к modeman и Magento Composer. modeman вообще не работает с windows, а Magento Composer требует донастройки прав пользователя для своей работы. Поэтому вполне логично появилась мысль мигрировать на linux. Лишней машины у меня нет, да и переключаться между двумя наборами клавиатур/мышек не комфортно, а виртуальных linux-серверов (именно серверов, а не десктопных рабочих станций) — штук 5. Поэтому и родилась идея запустить phpStorm на удаленном сервере с доступом с wind'ы. Чтобы можно было в linux-среде изучить возможности развертывания через Magento Composer (hardlinks!!!) без разрушения основной рабочей среды (Windows) и не создавать при этом новых инсталляций.
Этот пост родился в силу того, что я только в одном месте нашел указание на последовательность действий при запуске x-приложений на linux-машине с доступом к ним с windows-машин через Xming. Если бы я сразу вышел вот на эту страницу, я бы и написал этот пост, но так как я потратил довольно много времени на «плутание в трех соснах», да и чтобы закрепить результат, я написал пост в Хабр (хотя мог и в корпоративную вики).
Кстати, так можно и не только PhpStorm запускать, но и другие x-приложения с удаленной машины. И я использовал PhpStorm как локально (из офиса), так и удаленно (из дома) — вполне рабочее решение. Особого дискомфорта я не испытал, правда у нас интернет довольно хороший. Посмотрю еще VirtualBox, если получится разобраться с ним и развернуть рабочую среду за пару-тройку часов.