Кипели котлы, пот лился ручьями, команда разработчиков не покладая рук пилила проекты на symfony. Production на удалённой VDS, Ubuntu 16, со всем необходимым окружением. Главные репозитории в GitLab — бесплатном аналоге GitHub. Каждый разработчик удаленно трудится над проектами на своих локальных машинах, работая с клоном репозитория и проверяя все доработки на встроенном в symfony веб-сервере. Однажды в команду на фронт привлекли человека, который работал на windows, который понятия не имел о развёртке рабочего окружения. Только в этот момент мы осознали, что в до этого в команде на windows никто не работает. Только в этот момент встала актуальная задача «Как малой кровью и с минимумом знаний можно развернуть среду для разработки проектов symfony на винде». Нужно было написать краткий мануал для разработчиков, которые сидят на windows. В итоге решили, что мануал должен быть в виде статьи на Хабре. Забегая вперёд, скажу сразу, что для поиска решения мы начали стрелять из базуки по воробьям и только потом, осознав, какого монстра вызываем, начали искать что-то попроще.  Да, docker очень крутая штука, набирающая популярность чудовищными темпами. Даже нашли несколько полуфабрикатов, таких как bitnami-docker-symfony. Есть предчувствие, что на docker можно развернуть всё необходимое окружение, но два дня раскуривания мануалов не привели к результату. Если кто-то когда сделает мануал развертки окружения symfony с помощью docker, отвечающий всем требованиям, обозначенным выше, я непременно укажу его здесь. Решение было непонятно в первую очередь для нас, готовые решения не отвечали требованиям, а значит это не подходило. Мы смогли развернуть окружение на vagrant homestead. Но весь процесс по трудозатратам сродни поднятию веб-сервера с нуля с той лишь разницей, что не нужно вручную ставить некоторые компоненты, а значит, не отвечал принципу понятности для windows разработчика. Если интересно, отдельно я напишу мануал, как разворачивать проекты symfony с помощью vagrant. Но скажу сразу, это тоже работа с виртуальной машиной, почему-то проекты symfony не кэшировались и от того, загружались чудовищно долго. Опять таки, без изменения app_dev.php режим отладки был недоступен, т.к. при загрузке проекта на локальной машине по факту шло обращение к веб-серверу, который работал на виртуальной машине. И да, база данных также была на виртуалке... По иронии судьбы простое решение пришло в самом конце Мне стало интересно, как же всё таки развернуть окружение для проектов symfony нормально, ведь вполне возможно, что в итоге это будет проще и правильнее. Что включает окружение: В поисках установщиков 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 локально и дело сделано. Для работы c git прекрасно подойдет Git SCM — набор полезных ништяков:

git bash — консоль, которая выполняет команды привычным для *nix пользователей (в т.ч. генерирование ключей open rsa);
git GUI — графический интерфейс для работы с git;
Shell интегратор, который позволяет запустить консоль в нужной директории правым кликом по нужной папке Если будет интересно, могу отдельно опубликовать мануал по полной настройке git на windows, созданию ключей rsa, клонированию удалённых репозиториев. Любой проект 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 последовательно выполняем несколько команд: Если в ходе этих процессов не возникло никаких ошибок, можно начать работать над проектом и его отладкой В директории проекта с помощью Git Bash выполняем команду: В любом любимом IDE подключаемся к проекту symfony на локальной машине без необходимости синхронизировать файлы с удалённым серввером. В любимом браузере открываем localhost:8000 — открывается ваш проект symfony, делаем его отладку сразу на локальной машине, причем в режиме дебага. Коммитим все изменения и наработки, пушим их на сервер с помощью любимой Git GUI, или той, которая была предложена выше. Рабочее окружение для symfony настроено с минимальной кровью, работает на локальной машине, windows разработчик может начать делать своё дело. Возможно есть и другие решения, и с тем же docker, и решение c xampp не имеет недостатков, но оно позволило быстро и просто развернуть всё, что нужно для работы, причем согласно всем исходным требованиям. Если есть другие, не менее простые решения, прошу в комментариях.