Как настроить процесс билдинга и деплоя web приложений?

Question

[Андрей]

В данный момент в организации осуществлена следующая модель разработки web приложений:

Есть виртуальный хостинг с ftp и ssh, nginx, php5.5( обычный хостинг для сайтов ). У разработчиков нет локального сервера.

Разработчики заливают или синхронизируют проект по ftp с хостинга с помощью PhpStorm.
При разработке изменения заливаются сразу на хостинг. За мержинг кода отвечает PhpStorm.
При релизе выкачиваем сырцы и заливаем на хостинг(продакшен) заказчика.

Мы понимаем, что данная модель сильно устарела.

Думаем, что нужно вести проекты на BitBucket. ( Может есть что-то лучше? )

Как вести проекты на локальном сервере?
И какими технологиями лучше воспользоваться ( Vagrant, Docker... ), чтобы не использовать OpenServer и подобные?

Так же возникает вопрос как автоматизировать процесс деплоя на dev|production хостинги|сервера.

При разработке используются разные технологии SASS, LESS, JSX.
Как можно было бы автоматизировать процесс билдинга( компилирования SASS, сжатия JS и CSS) при деплое на продакшен сервер?
Как билдить проект когда он основан на фреймворке( используем Laravel или самопис )?

Главное интересует как автоматизировать процесс, чтобы не усложнять жизнь разработчикам?

Может стоит отказаться от такого хостинга в пользу DigitalOcean или подобным?

Comments

[Максим Тимофеев]

За мержинг кода отвечает PhpStorm.

А можно подробнее или ссылочку на доки. Как правильно для этого настроить PhpStorm?

[jacksparrow]

Максим Тимофеев: Отбросьте эту мысль, синхронизация из продакшена через шторм = бред

[Максим Тимофеев]

jacksparrow: А в аспекте одного разработчика?

[Андрей]

Максим Тимофеев: https://www.jetbrains.com/help/phpstorm/2016.1/com...

[jacksparrow]

Максим Тимофеев: Диф всеравно смотреть стоит через гит, а не сравнить с версией на сервере

Answer 1

[jacksparrow]

Сначало думал вас послать в гугл, но
Начните потихоньку, найденные в гугл схемы сложно сразу полностью применять с нуля.
Заведите гит репозиторий, разницы между битбакет или гитхаб на начальном этапе не будет.
По поводу опенсервера, лучше он, чем отсутсвие локального сервера. Как компромис между простотой развертки и 'правильностью" могу порекомендовать homestead - готовый бокс (от создателей ларавел).
Следующий этап - тесты автоматические, покрываете ими код. Их будет гонять система автоматического тестирования. Все эти системы имеют возможности последовательной сборки проекта, включая минификацию ксс и жс, разгогрев кеша и тд.
И вот только тогда можно переходить на автоматический деплой.
Добавленно: обратите внимание на методологию git flow для организации веток гита

Answer 2

[Anton Bormotov]

Мы использовали связку teamcity/ansible/cloudformation, сейчас это работает для QA окружения - развертывания определенной ветки (branches) на ресурсах aws.

Кратко алгоритм такой:
1) Разработчик закончил определенную задачу (feature/example)
2) Заходит в teamcity, запускает сборку (нажимает на кнопку)
3) Вводит необходимые данные: выбирает свою ветку (branch), выбирает опции, нужен ему только frontend/backend/cms (роли в ansible) или и то и другое, нужен ли ему отдельный cdn (cloudfront) и т. п.
4) Teamcity собирает исходники (composer, npm, grunt), ansible развертывает ec2 инстанс и требуемые ресурсы (r53 доменное имя, cloudfront distribution), конфигурирует его, закачиват собраные исходники.
5) Высылает письмо с выходными данными - доменным именем, ip адресом и т.п.

Если Вам интересно, пишите, могу помочь, с чего начать.
Сразу все поднять не всегда получается, мы делали это руками какое то время, что бы автоматизировать все случаи.