Кипели котлы, пот лился ручьями, команда разработчиков не покладая рук пилила проекты на 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 не имеет недостатков, но оно позволило быстро и просто развернуть всё, что нужно для работы, причем согласно всем исходным требованиям.
Если есть другие, не менее простые решения, прошу в комментариях.
ссылка на оригинал статьи https://habrahabr.ru/post/324304/
Добавить комментарий