Кипели котлы, пот лился ручьями, команда разработчиков не покладая рук пилила проекты на symfony.
Production на удалённой VDS, Ubuntu 16, со всем необходимым окружением. Главные репозитории в GitLab — бесплатном аналоге GitHub. Каждый разработчик удаленно трудится над проектами на своих локальных машинах, работая с клоном репозитория и проверяя все доработки на встроенном в symfony веб-сервере.
Однажды в команду на фронт привлекли человека, который работал на windows, который понятия не имел о развёртке рабочего окружения. Только в этот момент мы осознали, что в до этого в команде на windows никто не работает. Только в этот момент встала актуальная задача «Как малой кровью и с минимумом знаний можно развернуть среду для разработки проектов symfony на винде».
Нужно было написать краткий мануал для разработчиков, которые сидят на windows. В итоге решили, что мануал должен быть в виде статьи на Хабре.
Забегая вперёд, скажу сразу, что для поиска решения мы начали стрелять из базуки по воробьям и только потом, осознав, какого монстра вызываем, начали искать что-то попроще.
Какие требования к окружению
- Простота и скорость для нас — развертка окружения, исходных пакетов и т.п. должна была выполняться с максимально быстро, чтобы уже существующая команда не тратила на это много времени
- Понятность для нас — решение не должно было быть принципиально новым, чтобы для его понимания требовалось раскурить тонны мануалов
- Простота, скорость, понятность для разработчика windows — если для людей, привычных к linux системам работа с консолью, установка компонентов и т.п. — дело привычное, то у тех, кто работает на windows, от различных конфигов, логов и записей в cmd.exe может сложиться впечатление, что их комп вот-вот хакнут.
- Работа над проектом в привычном IDE — есть IDE, которые прекрасно цепляются к удалённым проектам, в режиме онлайн синхронизируют все изменения и т.п., но такие IDE не всегда удобны, бесплатны и понятны разработчику, кроме того, если он работает с разными заказчиками, менять IDE под заказчика по меньшей мере странно. Из-за этого возникают дополнительные требования.
- Отладка symfony проекта на локальной машине — отладка symfony на локальной машине выполняется запуском встроенного веб-сервера командой «php bin/console server:run». Это очень круто, т.к. просматривать результаты своей работы можно через localhost:8000 в т.ч. в режиме debug (/app_dev.php). Когда проект запускается удаленно, режим дебага не работает, пока соответствующие изменения не будут внесены в /web/app_dev.php.
- Работа с локальным клоном git репозитория — делать комиты, пуллы и т.п. проще и удобнее в привычной IDE (нежели с консоли)
С чего начали
Docker
Да, docker очень крутая штука, набирающая популярность чудовищными темпами. Даже нашли несколько полуфабрикатов, таких как bitnami-docker-symfony.
Есть предчувствие, что на docker можно развернуть всё необходимое окружение, но два дня раскуривания мануалов не привели к результату. Если кто-то когда сделает мануал развертки окружения symfony с помощью docker, отвечающий всем требованиям, обозначенным выше, я непременно укажу его здесь.
Решение было непонятно в первую очередь для нас, готовые решения не отвечали требованиям, а значит это не подходило.
Vagrant
Мы смогли развернуть окружение на vagrant homestead. Но весь процесс по трудозатратам сродни поднятию веб-сервера с нуля с той лишь разницей, что не нужно вручную ставить некоторые компоненты, а значит, не отвечал принципу понятности для windows разработчика.
Если интересно, отдельно я напишу мануал, как разворачивать проекты symfony с помощью vagrant. Но скажу сразу, это тоже работа с виртуальной машиной, почему-то проекты symfony не кэшировались и от того, загружались чудовищно долго. Опять таки, без изменения app_dev.php режим отладки был недоступен, т.к. при загрузке проекта на локальной машине по факту шло обращение к веб-серверу, который работал на виртуальной машине. И да, база данных также была на виртуалке...
По иронии судьбы простое решение пришло в самом конце
XAMMP
Мне стало интересно, как же всё таки развернуть окружение для проектов symfony нормально, ведь вполне возможно, что в итоге это будет проще и правильнее. Что включает окружение:
- php
- mysql (или другие бд, но мы работаем с mysql)
- composer
- Git
- Ide
- symfony
1. XAMMP — для php, mysql
В поисках установщиков php для windows я наткнулся на XAMPP — среду для разработки php. Она содержит все нужные компоненты (php, mysql, apache, phpmyqdmin и многое другое), управляется из графического интерфейса, по клику мыши включает нужные сервисы, устанавливается с простого установщика («далее», «далее», «далее»… )
Php и mysql — всё что нужно для отладки уже готового проекта symfony. Включаем mysql в xampp, из run.exe запускаем «php bin/console server:run» в директории проекта, и всё, сайт открывается в браузере по адресу localhost:8000, причем в режиме отладки без изменения app_dev.php
Наверное, существование xampp не станет новостью для многих хабравчан, но поверьте, после всех атомных бомб в лице докеров, вагрантов и т.п., которые мы сбрасывали на мух, это показалось чудом.
Дело за малым, нужен git, чтобы взаимодействовать с удаленным репозиторием, composer — чтобы загружать компоненты проекта symfony локально и дело сделано.
2. Git — для связи с репозиторием.
Для работы c git прекрасно подойдет Git SCM — набор полезных ништяков:
git bash — консоль, которая выполняет команды привычным для *nix пользователей (в т.ч. генерирование ключей open rsa);
git GUI — графический интерфейс для работы с git;
Shell интегратор, который позволяет запустить консоль в нужной директории правым кликом по нужной папке
Если будет интересно, могу отдельно опубликовать мануал по полной настройке git на windows, созданию ключей rsa, клонированию удалённых репозиториев.
3. Composer — для установки компонентов и библиотек проектов symfony.
Ставим composer, разворачиваем проект
Любой проект symfony помимо собственно файлов проекта содержит тысячи файлов библиотек и кэша. Копирование всей директории развернутого проекта с удаленного сервера — история на 1-3 часа. Именно поэтому, по умолчанию все компоненты и кэш находятся в .gitignore и не переносятся при клонировании репозитория.
Чтобы развернуть все нужные компоненты нужен composer. Качаем, ставим. Теперь из Git Bash терминала (да и из обычного скучного виндовсоского) можно запускать composer.
Открываем терминал в директории проекта symfony, запускаем команду:
composer install.
В ходе установки нужно будет внести данные, связанные с доступом к базе данных, настройке почтового сервера и т.п. Можно указать данные сразу, можно потом. В любом случае, без базы данных composer install завершиться красной руганью консольных логов, но это не должно пугать.
Настраиваем базу данных
Создать базу данных можно как из командной строки, так и из phpmyadmin, который входит в xampp. Открываем xampp, включаем mysql, apache, выбираем admin, рядом с mysql. Откроется phpmyadmin. Как в нём создать базу данных и пользователя, я думаю, объяснять не нужно
Параметры новой базы данных и пользователя нужно ввести в конфиге symfony проекта (app/config/parameters.yml)
Далее базу данных нужно привести в соответствие с той структурой, которая задана в проекте symfony. Для этого в директории проекта с помощью Git Bash последовательно выполняем несколько команд:
php bin/console doctrine:database:drop -- force
php bin/console doctrine:database:create
php bin/console doctrine:schema:update -- force
php bin/console doctrine:schema:validateЕсли в ходе этих процессов не возникло никаких ошибок, можно начать работать над проектом и его отладкой
Запускаем внутренний веб-сервер
В директории проекта с помощью Git Bash выполняем команду:
php bin/console server:runВ любом любимом IDE подключаемся к проекту symfony на локальной машине без необходимости синхронизировать файлы с удалённым серввером.
В любимом браузере открываем localhost:8000 — открывается ваш проект symfony, делаем его отладку сразу на локальной машине, причем в режиме дебага.
Коммитим все изменения и наработки, пушим их на сервер с помощью любимой Git GUI, или той, которая была предложена выше.
Резюме
Рабочее окружение для symfony настроено с минимальной кровью, работает на локальной машине, windows разработчик может начать делать своё дело.
Возможно есть и другие решения, и с тем же docker, и решение c xampp не имеет недостатков, но оно позволило быстро и просто развернуть всё, что нужно для работы, причем согласно всем исходным требованиям.
Если есть другие, не менее простые решения, прошу в комментариях.
Комментарии (30)
Juma
19.03.2017 17:22А тот самый разработчик сидящий на винде, разве у него нет своего предпочтительного окружения, на котором он может поднять что угодно?
masterdrew
19.03.2017 20:07+1Люди, которые сидят на фронтэнде, к сожалению, но в силу специфики, не всегда владеют тем, что происходит на сервере. Не говорю за всех, но, если, например, нужна только верстка, и человек хорошо делает верстку, он не всегда хочет и может погружаться во всё остальное. У него есть IDE, с помощью которого он клепал красивые страницы, но ни разу не разворачивал у себя окружение, которое может запустить php фреймворк или готовый движок.
Некоторые работают на удалённом сервере, но повторюсь, подключение к проектам symfony удалённо — плохой вариант по нескольким причинам:
1. не все IDE умеют синхронизировать реалтайм
2. если качать на ком всю директорию, адски долго
3. без доп настроек режим отладки в symfony работает только локально (настройки простые, но, на мой личный взгляд) лишние
4. если проект на сервере, то и git репозиторий на сервере. Допустим, на сервере нет графического интерфейса работы с git. Фронтенд разработчик должен делать комитыgit commit -a -m 'your commit message here'
подключившись к серверу по ssh? А если я не хочу давать доступ по ssh?
Ну и, наконец, фреймворк symfony изначально позиционирует возможность работать с ним локально. Значит нужно решение, которое позволяет работать с ним локально. Не на виртуальной машине, не на удалённом сервере, а именно локально. Кто с symfony не работал, тот не поймет.
StenHigh
19.03.2017 20:11Если интересно, отдельно я напишу мануал, как разворачивать проекты symfony с помощью vagrant
Есть прекрасные, понятные мануалы rus/eng от разработчиков самого homestead. По ним даже самый далекий от настройки среды человек поставит все это дело за 30 минут. У нас на проекте уже все перешли на такой вариант из за его простоты. Изоляция только плюс для вашей ОС. Доступ и работа с БД по ssh, работа с git с хостовой машины т.к. папка проектов пробрасывается с хостовой машины в виртуалку.masterdrew
19.03.2017 20:12Вы работаете с проектами на symfony? Они кэшируются? Какая скорость загрузки? Если да, поделитесь, как это настраивать.
SbWereWolf
19.03.2017 21:20опубликовать мануал по полной настройке git на windows
а что там настраивать? или в смысле какие два приложения установить, с какими настройками?masterdrew
19.03.2017 21:28Вроде того, да. В частности, что и откуда установить, как сгенерировать ключи, как подключить удаленный git-пепозиторий и клонировать с него проект себе на локальную машину. Знаю, мануалов много, но для некоторых людей всё неочевидно. Именно поэтому и написал, «если нужно — опубликую»)
SbWereWolf
19.03.2017 21:55как сгенерировать ключи
вот это не знаю что за фишка, а в остальном ставишь SourceTree и больше ни чего не требуется.
Если с composer понятно дело без командной строки не обойтись то в случаи системы контроля версий — графический интерфейс это то что надо.
Grox
19.03.2017 22:33Есть современный удобный проект Open Server — https://ospanel.io
Xampp это что-то из древнего прошлого, как и Denwer.
michael_vostrikov
20.03.2017 06:36+1то у тех, кто работает на windows, от различных конфигов, логов и записей в cmd.exe может сложиться впечатление, что их комп вот-вот хакнут.
Ну вот не нааадо говорить за всех)
По теме.
WAMP / XAMPP / OpenServer
TortoiseGit / SourceTree
HeidiSQL / MySQL Workbench
В каких-то случаях vagrant.
Для консоли Git Bash.
phpMyAdmin тормозной и неудобный, он только на крайний случай, лучше десктопные клиенты использовать.
erwin_shrodinger
20.03.2017 12:22а не проще было поставить вашему новому человеку ubuntu/elementary и помочь настроить всё по-вашему?
masterdrew
20.03.2017 12:29Вам, видимо, не до конца понятен кейс. Представьте, что разработчик на удалёнке, он привлекается для решения небольшой задачи, а не в штат на века, причем еще под вопросом уровень его компетенции, ответственности, готовности работать в обозначенных условиях. Что ж теперь, каждому разворачивать убунту, перестраивать его под своё рабочее окружение и т.д? Нужно максимально быстро включить человека в работу и проверить его в боевых условиях. Поставьте себя на место человека. Работаете вы себе спокойно на винде, верстаете странички, пишите простенький js, на стороне клиента. И тут вас привлекают для решения некоторых задач и говорят — «будешь использовать эту ОС, эту IDE, и т.д». Одним это покажется нормальным, другим — полным бредом.
erwin_shrodinger
20.03.2017 12:43да, задачу я понял неверно. мне показалось, что речь идёт именно о новом штатном сотруднике
sspat
20.03.2017 12:54+2Была та же проблема, на проект за два года привлекалось в общей сложности с десяток человек на временные работы по фронту, начинал так же с инструкции как поднять веб-сервер и php под windows, но что бы я не делал, у следующего всегда находилась какая-то уникальная ошибка на гугление и добавление в инструкцию которой тратилось время. После третьего или четвертого человека мне надоело бодаться с Win и потратив два вечера на настройку окружения под vagrant я забыл об этой проблеме навсегда. Две команды — и окружение готово, и никаких тебе хост-ос-специфичных проблем у каждого, какой бы балаган у него в винде не творился, окружение от этого изолировано. Как приятный бонус — vagrant share, можно смотреть что у него там происходит моментально если какой-то вопрос, без скриншотов, коммитов и т.д.
nitso
21.03.2017 13:01php 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.
ghost404
23.03.2017 11:02По собственному опыту скажу что XAMPP не лучшее решение.
Это только базовый веб-сервер.
Потом понадобится поставить Redis, Ruby, Java, SASS, Sphinx, Elasticsearch, APCu.
И весь этот зоопарк поддерживать на винде, никсах и маках.
С точки зрения разработки, Windows имеет массу недостатков. К описанным nitso проблемам, добавлю:
- тормоза Symfony на винде из-за особенностей файловой системы. APCu и OPcache помогают, но не спасают. Все равно скорость в 3 дольше. Использование встроенного php сервера просто самоубийство.
- частые проблемы с регистром имен файлов. Изменить регистр имени файла в git приходится делать 2 коммитами.
- сталкивался с тем, что MySQL в XAMPP работает не так же как и на CentOS и запросы которые на Windows проходили без проблем, ломали боевой сервер. Или данные хранились не в корректном формате.
- частая ситуация когда на винде все работает, а на никсах нет
AnisimovAM
29.03.2017 14:50Open Server не пробовали? С ним прекрасно работают проекты на симфони. Работал с ним 3 года, пока на линукс не перешел.
Fesor
Любой предложенный вариант будет конфликтовать с требованием:
Просто потому что "понятность" штука весьма и весьма субъективная. К примеру я могу взять человека без опыта работы с docker, дать ему ссылку на готовое окружение и глосарий терминов и человек уже часа через 2 поднимет свой проект. А быть может человеку для комфортной работы нужно досконально все изучить и только тогда для него все будет "понятно".
Мы же не говорим про docker как средство для изоляции и дистрибьюции окружения, так что все становится намного проще.
опять же есть готовые варианты.
И в итоге ваша статья свелась к простому "как поднять проект на symfony под XAMMP". На эту тему даже видосики на ютубе есть.
masterdrew
Тема к тому, что если нужно локальное окружение для symfony, которое позволяет вести отладку с помощью встроенного веб-сервера, не нужно усложнять, достаточно использовать xampp. Увы, не всегда сходу приходит именно простое решение.
Fesor
ну например с тем же docker или vagrant в чем удобство подхода, вы как разработчики можете сформировать готовый образ чтобы у того кто разворачивает проект было все необходимое. А так как речь идет только о dev окружении большую часть сложности этого процесса можно опустить.
А сам образ что в случае с docker что и в случае с vagrant можно сделать как обычно.
apt-get install phpи т.д. а потомdocker commit.masterdrew
Статья не посвящена тому, что docker не подходит. Но если его применение не на кончиках пальцев, то использование xampp куда быстрее и проще. А так, разумеется, что для человека, который уже владеет всеми возможностями docker, возможно, это не составит проблем.
Опять же, symfony рекомендует отладку в локальном окружении, а не на удаленных (или виртуальных) серверах.
Из недостатков, да — рабочее окружение только одно, нужно ставить доп. компоненты и т.п. Но если взять за отправную точку ситуацию, когда человек не владеет ни docker, ни vagrant, ни xampp, чем ему будет проще запустить php+mysql на локальной машине?
Fesor
если что-то крутится на вашем лэптопе, вне зависимости от того крутится это внутри системы виртуализации, под каким-то гипервизором или в lxc контейнере, это всеравно локальное окружение. Просто при помощи этих вещей мы можем "локальное окружение" максимально приблизить к продакшену, дабы фраза "у меня локально работает" вызывала хоть чуть-чуть больше вероятности что и на продакшене работать это будет.
алгоритм запуска проекта для разработчика:
Если что я пробовал все три алгоритма и с xampp/openserver всегда заканчивалось тем что я сам поднимал окружение на целевой машине. И как это весело когда фронтэндер зальет картинку "Logo.png" и у него все будет работать а у тебя — нет.
Естественно что чтобы первые два пункта работали, все разработчики должны делать точно так же. С другой стороны это упрощает последующие деплои и можно вообще полностью весь процесс управления инфраструктурой автоматизировать. Ну то есть мы говорим сейчас о снижении рисков.
masterdrew
Насчет stacker, интересно, посмотрю. Возможно это то, что нужно, но с ходу как решение не нашлось.
MaxZN
Stacker обновился до первой стабильной версии. Вы уже пробовали ставить на винду? Интересен ваш опыт в этом плане, так как на macos и linux работает все превосходно, а обратной связи от обладателей win еще не поступало.
В планах переписать ролики с вычиткой, ждем пока микрофон с али придет.
А вообще, касаемо статьи, у нас таже боль была, привлекаемые периодически товарищи верстальщики и фронтендеры некоторые даже понятия не имели, как наше окружение ставить. Плюс те кто постоянно работали уже утомились от периодических реплик, вроде: — А у меня локально все работает…
Все сошлись во мнении, что у команды должно стоять идентичное окружение и это окружение не должно бадаться с тем, что уже стоит(это больше для привлекаемых на время сотрудников) Только на винду не ставили пока ни разу, как то не довелось. Поэтому, отпишитесь плиз, очень интересует, как проходит установка и насколько сложно.