Как стать автором
Обновить

Комментарии 31

Если кто-то когда сделает мануал развертки окружения symfony с помощью docker, отвечающий всем требованиям, обозначенным выше, я непременно укажу его здесь.

Любой предложенный вариант будет конфликтовать с требованием:


Понятность для нас — решение не должно было быть принципиально новым, чтобы для его понимания требовалось раскурить тонны мануалов

Просто потому что "понятность" штука весьма и весьма субъективная. К примеру я могу взять человека без опыта работы с docker, дать ему ссылку на готовое окружение и глосарий терминов и человек уже часа через 2 поднимет свой проект. А быть может человеку для комфортной работы нужно досконально все изучить и только тогда для него все будет "понятно".


Мы же не говорим про docker как средство для изоляции и дистрибьюции окружения, так что все становится намного проще.


Если интересно, отдельно я напишу мануал, как разворачивать проекты symfony с помощью vagrant

опять же есть готовые варианты.


И в итоге ваша статья свелась к простому "как поднять проект на symfony под XAMMP". На эту тему даже видосики на ютубе есть.

Тема к тому, что если нужно локальное окружение для symfony, которое позволяет вести отладку с помощью встроенного веб-сервера, не нужно усложнять, достаточно использовать xampp. Увы, не всегда сходу приходит именно простое решение.

ну например с тем же docker или vagrant в чем удобство подхода, вы как разработчики можете сформировать готовый образ чтобы у того кто разворачивает проект было все необходимое. А так как речь идет только о dev окружении большую часть сложности этого процесса можно опустить.


А сам образ что в случае с docker что и в случае с vagrant можно сделать как обычно. apt-get install php и т.д. а потом docker commit.

Статья не посвящена тому, что docker не подходит. Но если его применение не на кончиках пальцев, то использование xampp куда быстрее и проще. А так, разумеется, что для человека, который уже владеет всеми возможностями docker, возможно, это не составит проблем.
Опять же, symfony рекомендует отладку в локальном окружении, а не на удаленных (или виртуальных) серверах.
Из недостатков, да — рабочее окружение только одно, нужно ставить доп. компоненты и т.п. Но если взять за отправную точку ситуацию, когда человек не владеет ни docker, ни vagrant, ни xampp, чем ему будет проще запустить php+mysql на локальной машине?
Опять же, symfony рекомендует отладку в локальном окружении, а не на удаленных (или виртуальных) серверах.

если что-то крутится на вашем лэптопе, вне зависимости от того крутится это внутри системы виртуализации, под каким-то гипервизором или в lxc контейнере, это всеравно локальное окружение. Просто при помощи этих вещей мы можем "локальное окружение" максимально приблизить к продакшену, дабы фраза "у меня локально работает" вызывала хоть чуть-чуть больше вероятности что и на продакшене работать это будет.


Но если взять за отправную точку ситуацию, когда человек не владеет ни docker, ни vagrant, ни xampp, чем ему будет проще запустить php+mysql на локальной машине?

алгоритм запуска проекта для разработчика:


  • Vagrant
    • склонить проект
    • поставить vagrant (иногда надо еще просить какой-нибудь ansible поставить но это если мы хотим то же окружение еще и в прод выкатывать, не наш случай).
    • сделать vagrant up
    • делать дела
  • Docker:
    • Поставь себе docker
    • склонь проект
    • запусти docker-compose up -d
    • делай дела
  • XAMPP/OpenServer
    • Поставь TeamViewer и я тебе быстро сам все настрою
    • делай дела

Если что я пробовал все три алгоритма и с xampp/openserver всегда заканчивалось тем что я сам поднимал окружение на целевой машине. И как это весело когда фронтэндер зальет картинку "Logo.png" и у него все будет работать а у тебя — нет.


Естественно что чтобы первые два пункта работали, все разработчики должны делать точно так же. С другой стороны это упрощает последующие деплои и можно вообще полностью весь процесс управления инфраструктурой автоматизировать. Ну то есть мы говорим сейчас о снижении рисков.

Насчет stacker, интересно, посмотрю. Возможно это то, что нужно, но с ходу как решение не нашлось.
Stacker обновился до первой стабильной версии. Вы уже пробовали ставить на винду? Интересен ваш опыт в этом плане, так как на macos и linux работает все превосходно, а обратной связи от обладателей win еще не поступало.

В планах переписать ролики с вычиткой, ждем пока микрофон с али придет.

А вообще, касаемо статьи, у нас таже боль была, привлекаемые периодически товарищи верстальщики и фронтендеры некоторые даже понятия не имели, как наше окружение ставить. Плюс те кто постоянно работали уже утомились от периодических реплик, вроде: — А у меня локально все работает…
Все сошлись во мнении, что у команды должно стоять идентичное окружение и это окружение не должно бадаться с тем, что уже стоит(это больше для привлекаемых на время сотрудников) Только на винду не ставили пока ни разу, как то не довелось. Поэтому, отпишитесь плиз, очень интересует, как проходит установка и насколько сложно.
VirtualBox же. К чему эти различия между инженерной и целевой системами…
А тот самый разработчик сидящий на винде, разве у него нет своего предпочтительного окружения, на котором он может поднять что угодно?
Люди, которые сидят на фронтэнде, к сожалению, но в силу специфики, не всегда владеют тем, что происходит на сервере. Не говорю за всех, но, если, например, нужна только верстка, и человек хорошо делает верстку, он не всегда хочет и может погружаться во всё остальное. У него есть IDE, с помощью которого он клепал красивые страницы, но ни разу не разворачивал у себя окружение, которое может запустить php фреймворк или готовый движок.
Некоторые работают на удалённом сервере, но повторюсь, подключение к проектам symfony удалённо — плохой вариант по нескольким причинам:
1. не все IDE умеют синхронизировать реалтайм
2. если качать на ком всю директорию, адски долго
3. без доп настроек режим отладки в symfony работает только локально (настройки простые, но, на мой личный взгляд) лишние
4. если проект на сервере, то и git репозиторий на сервере. Допустим, на сервере нет графического интерфейса работы с git. Фронтенд разработчик должен делать комиты
git commit -a -m 'your commit message here'

подключившись к серверу по ssh? А если я не хочу давать доступ по ssh?
Ну и, наконец, фреймворк symfony изначально позиционирует возможность работать с ним локально. Значит нужно решение, которое позволяет работать с ним локально. Не на виртуальной машине, не на удалённом сервере, а именно локально. Кто с symfony не работал, тот не поймет.
На мой взгляд, openserver куда удобнее xampp-а. Проще работать с сайтами.
А не русскоязычная документация у него найдётся?
Поддерживаю, если не docker и не vagrant, то мой выбор однозначно openserver.
Если интересно, отдельно я напишу мануал, как разворачивать проекты symfony с помощью vagrant
Есть прекрасные, понятные мануалы rus/eng от разработчиков самого homestead. По ним даже самый далекий от настройки среды человек поставит все это дело за 30 минут. У нас на проекте уже все перешли на такой вариант из за его простоты. Изоляция только плюс для вашей ОС. Доступ и работа с БД по ssh, работа с git с хостовой машины т.к. папка проектов пробрасывается с хостовой машины в виртуалку.
Вы работаете с проектами на symfony? Они кэшируются? Какая скорость загрузки? Если да, поделитесь, как это настраивать.
опубликовать мануал по полной настройке git на windows

а что там настраивать? или в смысле какие два приложения установить, с какими настройками?
Вроде того, да. В частности, что и откуда установить, как сгенерировать ключи, как подключить удаленный git-пепозиторий и клонировать с него проект себе на локальную машину. Знаю, мануалов много, но для некоторых людей всё неочевидно. Именно поэтому и написал, «если нужно — опубликую»)
как сгенерировать ключи

вот это не знаю что за фишка, а в остальном ставишь SourceTree и больше ни чего не требуется.

Если с composer понятно дело без командной строки не обойтись то в случаи системы контроля версий — графический интерфейс это то что надо.
как сгенерировать ключи

вы про ssh-keygen?

С этим не поспоришь. Последняя версия 2015 году, что удивило.

эм… я вижу сходу релиз за 24 декабря 2016-ого.

то у тех, кто работает на windows, от различных конфигов, логов и записей в cmd.exe может сложиться впечатление, что их комп вот-вот хакнут.

Ну вот не нааадо говорить за всех)


По теме.


WAMP / XAMPP / OpenServer
TortoiseGit / SourceTree
HeidiSQL / MySQL Workbench


В каких-то случаях vagrant.
Для консоли Git Bash.
phpMyAdmin тормозной и неудобный, он только на крайний случай, лучше десктопные клиенты использовать.

OpenServer лучше, чем XAMMP.

Хотя бы тем, что XAMMP у меня установить когда-то не получилось, а OpenServer встал сразу и работает по сей день. Denwer устарел, это да )

Из Git-оболочек лучший SmartGit. Пробовал SourceTree и TortoiseGit, а также клиент Гитхаба. Поэтому есть с чем сравнить.
а не проще было поставить вашему новому человеку ubuntu/elementary и помочь настроить всё по-вашему?
Вам, видимо, не до конца понятен кейс. Представьте, что разработчик на удалёнке, он привлекается для решения небольшой задачи, а не в штат на века, причем еще под вопросом уровень его компетенции, ответственности, готовности работать в обозначенных условиях. Что ж теперь, каждому разворачивать убунту, перестраивать его под своё рабочее окружение и т.д? Нужно максимально быстро включить человека в работу и проверить его в боевых условиях. Поставьте себя на место человека. Работаете вы себе спокойно на винде, верстаете странички, пишите простенький js, на стороне клиента. И тут вас привлекают для решения некоторых задач и говорят — «будешь использовать эту ОС, эту IDE, и т.д». Одним это покажется нормальным, другим — полным бредом.
да, задачу я понял неверно. мне показалось, что речь идёт именно о новом штатном сотруднике
НЛО прилетело и опубликовало эту надпись здесь

php bin/console server:run в большинстве случаев прекрасно работает в windows-окружении. Минус — все запросы (в т.ч. статичные ресурсы) обрабатываются symfony, что уменьшает общую производительность и делает процесс загрузки сайта однопоточным.


С первичным разворачиванием проекта прекрасно справляется composer: настройте create-project, и все необходимые манипуляции он выполнит сам. В composer есть отдельный хук для этого случая: post-create-project-cmd — туда можно добавить накат базы, миграции и остальные скрипты (не влияя на процесс разворачивания проекта во время деплоя — там обычно используется composer install).


В идеальном случае все сводится к двум командам:


$ composer create-project vendor/project
$ php app/console server:run

В целом, при кросс-платформенной разработке следует иметь ввиду:


  • непереносимые расширения php (posix, threads, когда-то были вопросы с amqp, memcached — прошу поправить по актуальности) — для большинства проблемных клиентов, как правило, есть реализация на php
  • абсолютные пути, camelCase, особенности окружения — с этим просто нужно быть аккуратным
  • миграции и "сырые" sql-запросы при использовании разных БД.

По последнему пункту есть опыт использования doctrine в трех БД: in-memory sqlite для тестов, mysql в разработке, oracle в продакшне. На одной кодовой базе. Не без костылей, но работает стабильно. Материала наверное хватит на небольшую статью, если интересно.


Отдельно хочется упомянуть быстродействие тяжелых symfony-проектов (например, Sonata) в dev-режиме на windows. В сравнении, на одной и той же машине 0.5-1с в linux-окружении и 3-5с в windows на открытие одной и той же страницы. Хорошо можно ускорить если отключить целиком xdebug (подключать руками при необходимости), отключить web-profiler-bundle, подключить кэши. Все, кроме xdebug, без головной боли делается через отдельное окружение.


И моё личное имхо: cygwin вместо gitbash.
И P.S.: для комфортной работы в консоли в windows (в т.ч. и cmd, и gitbash, и cygwin) есть замечательный проект — conemu.

По собственному опыту скажу что XAMPP не лучшее решение.
Это только базовый веб-сервер.
Потом понадобится поставить Redis, Ruby, Java, SASS, Sphinx, Elasticsearch, APCu.
И весь этот зоопарк поддерживать на винде, никсах и маках.


С точки зрения разработки, Windows имеет массу недостатков. К описанным nitso проблемам, добавлю:


  • тормоза Symfony на винде из-за особенностей файловой системы. APCu и OPcache помогают, но не спасают. Все равно скорость в 3 дольше. Использование встроенного php сервера просто самоубийство.
  • частые проблемы с регистром имен файлов. Изменить регистр имени файла в git приходится делать 2 коммитами.
  • сталкивался с тем, что MySQL в XAMPP работает не так же как и на CentOS и запросы которые на Windows проходили без проблем, ломали боевой сервер. Или данные хранились не в корректном формате.
  • частая ситуация когда на винде все работает, а на никсах нет
Open Server не пробовали? С ним прекрасно работают проекты на симфони. Работал с ним 3 года, пока на линукс не перешел.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории