19 марта в 15:43

Развертка среды разработки Symfony под Windows tutorial

Кипели котлы, пот лился ручьями, команда разработчиков не покладая рук пилила проекты на symfony.


Production на удалённой VDS, Ubuntu 16, со всем необходимым окружением. Главные репозитории в GitLab — бесплатном аналоге GitHub. Каждый разработчик удаленно трудится над проектами на своих локальных машинах, работая с клоном репозитория и проверяя все доработки на встроенном в symfony веб-сервере.


Однажды в команду на фронт привлекли человека, который работал на windows, который понятия не имел о развёртке рабочего окружения. Только в этот момент мы осознали, что в до этого в команде на windows никто не работает. Только в этот момент встала актуальная задача «Как малой кровью и с минимумом знаний можно развернуть среду для разработки проектов symfony на винде».


Нужно было написать краткий мануал для разработчиков, которые сидят на windows. В итоге решили, что мануал должен быть в виде статьи на Хабре.


image

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


Какие требования к окружению


  • Простота и скорость для нас — развертка окружения, исходных пакетов и т.п. должна была выполняться с максимально быстро, чтобы уже существующая команда не тратила на это много времени
  • Понятность для нас — решение не должно было быть принципиально новым, чтобы для его понимания требовалось раскурить тонны мануалов
  • Простота, скорость, понятность для разработчика 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 и многое другое), управляется из графического интерфейса, по клику мыши включает нужные сервисы, устанавливается с простого установщика («далее», «далее», «далее»… )


image

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 не имеет недостатков, но оно позволило быстро и просто развернуть всё, что нужно для работы, причем согласно всем исходным требованиям.


Если есть другие, не менее простые решения, прошу в комментариях.

Андрей Радченко @masterdrew
карма
2,0
рейтинг 0,0
Самое читаемое Разработка

Комментарии (30)

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

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


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

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


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


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

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


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

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

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


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

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


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

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

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

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

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

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

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

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

        вы про ssh-keygen?

  • 0
    Есть современный удобный проект Open Server — https://ospanel.io
    Xampp это что-то из древнего прошлого, как и Denwer.
    • 0
      С этим не поспоришь. Последняя версия 2015 году, что удивило.
      • 0

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

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

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


    По теме.


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


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

  • 0
    а не проще было поставить вашему новому человеку ubuntu/elementary и помочь настроить всё по-вашему?
    • 0
      Вам, видимо, не до конца понятен кейс. Представьте, что разработчик на удалёнке, он привлекается для решения небольшой задачи, а не в штат на века, причем еще под вопросом уровень его компетенции, ответственности, готовности работать в обозначенных условиях. Что ж теперь, каждому разворачивать убунту, перестраивать его под своё рабочее окружение и т.д? Нужно максимально быстро включить человека в работу и проверить его в боевых условиях. Поставьте себя на место человека. Работаете вы себе спокойно на винде, верстаете странички, пишите простенький js, на стороне клиента. И тут вас привлекают для решения некоторых задач и говорят — «будешь использовать эту ОС, эту IDE, и т.д». Одним это покажется нормальным, другим — полным бредом.
      • 0
        да, задачу я понял неверно. мне показалось, что речь идёт именно о новом штатном сотруднике
  • +2
    Была та же проблема, на проект за два года привлекалось в общей сложности с десяток человек на временные работы по фронту, начинал так же с инструкции как поднять веб-сервер и php под windows, но что бы я не делал, у следующего всегда находилась какая-то уникальная ошибка на гугление и добавление в инструкцию которой тратилось время. После третьего или четвертого человека мне надоело бодаться с Win и потратив два вечера на настройку окружения под vagrant я забыл об этой проблеме навсегда. Две команды — и окружение готово, и никаких тебе хост-ос-специфичных проблем у каждого, какой бы балаган у него в винде не творился, окружение от этого изолировано. Как приятный бонус — vagrant share, можно смотреть что у него там происходит моментально если какой-то вопрос, без скриншотов, коммитов и т.д.
  • 0

    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.

  • 0

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


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


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

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.