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


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

Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 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 года, пока на линукс не перешел.

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