Комментарии 31
Если кто-то когда сделает мануал развертки окружения symfony с помощью docker, отвечающий всем требованиям, обозначенным выше, я непременно укажу его здесь.
Любой предложенный вариант будет конфликтовать с требованием:
Понятность для нас — решение не должно было быть принципиально новым, чтобы для его понимания требовалось раскурить тонны мануалов
Просто потому что "понятность" штука весьма и весьма субъективная. К примеру я могу взять человека без опыта работы с docker, дать ему ссылку на готовое окружение и глосарий терминов и человек уже часа через 2 поднимет свой проект. А быть может человеку для комфортной работы нужно досконально все изучить и только тогда для него все будет "понятно".
Мы же не говорим про docker как средство для изоляции и дистрибьюции окружения, так что все становится намного проще.
Если интересно, отдельно я напишу мануал, как разворачивать проекты symfony с помощью vagrant
опять же есть готовые варианты.
И в итоге ваша статья свелась к простому "как поднять проект на symfony под XAMMP". На эту тему даже видосики на ютубе есть.
ну например с тем же docker или vagrant в чем удобство подхода, вы как разработчики можете сформировать готовый образ чтобы у того кто разворачивает проект было все необходимое. А так как речь идет только о dev окружении большую часть сложности этого процесса можно опустить.
А сам образ что в случае с docker что и в случае с vagrant можно сделать как обычно. apt-get install php
и т.д. а потом docker commit
.
Опять же, 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" и у него все будет работать а у тебя — нет.
Естественно что чтобы первые два пункта работали, все разработчики должны делать точно так же. С другой стороны это упрощает последующие деплои и можно вообще полностью весь процесс управления инфраструктурой автоматизировать. Ну то есть мы говорим сейчас о снижении рисков.
В планах переписать ролики с вычиткой, ждем пока микрофон с али придет.
А вообще, касаемо статьи, у нас таже боль была, привлекаемые периодически товарищи верстальщики и фронтендеры некоторые даже понятия не имели, как наше окружение ставить. Плюс те кто постоянно работали уже утомились от периодических реплик, вроде: — А у меня локально все работает…
Все сошлись во мнении, что у команды должно стоять идентичное окружение и это окружение не должно бадаться с тем, что уже стоит(это больше для привлекаемых на время сотрудников) Только на винду не ставили пока ни разу, как то не довелось. Поэтому, отпишитесь плиз, очень интересует, как проходит установка и насколько сложно.
Некоторые работают на удалённом сервере, но повторюсь, подключение к проектам symfony удалённо — плохой вариант по нескольким причинам:
1. не все IDE умеют синхронизировать реалтайм
2. если качать на ком всю директорию, адски долго
3. без доп настроек режим отладки в symfony работает только локально (настройки простые, но, на мой личный взгляд) лишние
4. если проект на сервере, то и git репозиторий на сервере. Допустим, на сервере нет графического интерфейса работы с git. Фронтенд разработчик должен делать комиты
git commit -a -m 'your commit message here'
подключившись к серверу по ssh? А если я не хочу давать доступ по ssh?
Ну и, наконец, фреймворк symfony изначально позиционирует возможность работать с ним локально. Значит нужно решение, которое позволяет работать с ним локально. Не на виртуальной машине, не на удалённом сервере, а именно локально. Кто с symfony не работал, тот не поймет.
Если интересно, отдельно я напишу мануал, как разворачивать проекты symfony с помощью vagrantЕсть прекрасные, понятные мануалы rus/eng от разработчиков самого homestead. По ним даже самый далекий от настройки среды человек поставит все это дело за 30 минут. У нас на проекте уже все перешли на такой вариант из за его простоты. Изоляция только плюс для вашей ОС. Доступ и работа с БД по ssh, работа с git с хостовой машины т.к. папка проектов пробрасывается с хостовой машины в виртуалку.
опубликовать мануал по полной настройке git на windows
а что там настраивать? или в смысле какие два приложения установить, с какими настройками?
Xampp это что-то из древнего прошлого, как и Denwer.
то у тех, кто работает на windows, от различных конфигов, логов и записей в cmd.exe может сложиться впечатление, что их комп вот-вот хакнут.
Ну вот не нааадо говорить за всех)
По теме.
WAMP / XAMPP / OpenServer
TortoiseGit / SourceTree
HeidiSQL / MySQL Workbench
В каких-то случаях vagrant.
Для консоли Git Bash.
phpMyAdmin тормозной и неудобный, он только на крайний случай, лучше десктопные клиенты использовать.
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 проходили без проблем, ломали боевой сервер. Или данные хранились не в корректном формате.
- частая ситуация когда на винде все работает, а на никсах нет
Развертка среды разработки Symfony под Windows