Как правильно настраивать дев-окружение для веб-разработки?

Привет всем! Ребят, подскажите какие-то best practices как правильно организовывать dev окружение для веб-разработки. Имеется следующий конкретный кейс:

Международный портал, с несколькими отдельными сервисами. Например, как в Яндексе есть metrika.ya.ru, webmasters.yandex.ru, direct.yandex.ru и все это разные сервисы/кабинеты.

Тоже самое у нас, есть основной портал и несколько отдельных сервисов:
  • company.com
  • service1.company.com
  • service2.company.com
  • service3.company.com
  • admin.company.com


Допустим в компании работают три программиста. Есть dev-сервер со следующей структурой:
/home
	- vasya (dev1)
		- www
			- company
				- frontend
				- backend
				- service1
				- service2
				- service3
	- petya (dev2)
		- www
			- company
				- frontend
				- backend
				- service1
				- service2
				- service3
	- kolya (dev3)
		- www
			- company
				- frontend
				- backend
				- service1
				- service2
				- service3

есть отдельный домен: company-dev.com и настроены виртуальные хосты для каждого разработчика:

dev1.company-dev.com
dev1service1.company-dev.com
dev1service2.company-dev.com
dev1service3.company-dev.com
dev1admin.company-dev.com

dev2.company-dev.com
dev2service1.company-dev.com
dev2service2.company-dev.com
dev2service3.company-dev.com
dev2admin.company-dev.com

dev3.company-dev.com
dev3service1.company-dev.com
dev3service2.company-dev.com
dev3service3.company-dev.com
dev3admin.company-dev.com

Выглядит это как-то неправильно все. Не говоря уже о том, что в компании в разныз странах основной домен company.com может выглядеть как company.ru, company.de, company.fr etc.

Если в компании появляется новый разработчик, то приходится создавать ему 5 поддоменов и 5 виртуальных хостов.
Если в компании открывается какой-то новый сервис, то нужно добавить его каждому из трех (а в будущем больше) разработчиков.

Как сделать так, чтобы было 5 субдоменов на проде и 5 субдоменов на дев-сервере.
company.com 		-> company-dev.com
service1.company.com 	-> service1.company-dev.com
service2.company.com 	-> service2.company-dev.com
service3.company.com 	-> service3.company-dev.com
admin.company.com 	-> admin.company-dev.com

но каждый разработчик попадал в свою физическую папку? Чтоб не получилось, что три человека работают с одним файлом и мешают друг-другу. Кроме того, чтоб была возможность разработчику1 сказать тестеру или менеджеру, зайди ко мне посмотри оно работает. "зайди ко мне" имеется ввиду открыть его дев в браузере. Знаю что можно сделать своей ДНС сервер и для каждого сотрудника в компании по его айпи направлять его в нужную папку на сервере, хотя в браузере у всех будет один адрес. Но кажется что это слишком сложно. Может есть еще какие-то варианты... Как вообще люди это делают нормальные?

Есть еще мнение, что каждый разраб должен разворачивать себе локальное окружение на своем компе, но хз...

Кто решал подобные задачи, поделитесь советом, плз.
  • Вопрос задан
  • 4242 просмотра
Пригласить эксперта
Ответы на вопрос 4
@xfg
Не думайте о доменах. Вы смешали администрирование и программирование. Не нужно никакого dev сервера. Делайте работу на локальной dev машине, отправляйте изменения в удаленный репозиторий и всё. Можете вообще не устанавливать nginx/apache и т.д. на локальную dev машину, чтобы не забивать голову всякими доменами, а проект запускать под встроенным PHP сервером например из корня проекта и тогда будете обращаться к вашим сервисам по адресу localhost:port/service1/index.php, localhost:port/service2/index.php и т.д.

Домены будете создавать уже на продакшене. В простейшем случае склонируете на продакшн машину удаленный репозиторий проекта и в конфигах nginx нужно будет написать что-то типа такого

server {
  server_name company.com;
  root /home/www/company/frontend;
 ...
}
server {
  server_name admin.company.com;
  root /home/www/company/backend;
 ...
}
server {
  server_name service1.company.com;
  root /home/www/company/service1;
 ...
}
server {
  server_name service2.company.com;
  root /home/www/company/service2;
 ...
}


Есть еще мнение, что каждый разраб должен разворачивать себе локальное окружение на своем компе, но хз...

Так и делают. Разработчикам не нужен никакой dev сервер. Они клонируют репозиторий, делают что-то локально у себя и отправляют изменения в удаленный репозиторий. Для тестеров и всяких менеджеров просто поднимают так называемый stage-сервер где они и тестируют приложение, но это тоже самое что и продакшн сервер, просто доступ к нему только внутри компании. Можно настроить continuous integration чтобы все изменения из репозитория в master ветке автоматически бы приводили к деплою приложения на stage и продакшн сервера. Примерно так в общих словах устроена веб разработка.
Ответ написан
rpsv
@rpsv
делай либо хорошо, либо никак
Развернуть GIT?

Идеальной на мой взгляд будет схема:
  • [branch].company.com
  • [branch].service1.company.com


И собственно ветка будет не для разработчика, а для фичи/фикса/дева
Про структуру репозитория почитать можно тут: https://habrahabr.ru/post/106912/
Как это реализовать, я не подскажу, так что это не более чем концепт.

P.S. как по мне, если разработчики правят один и тот же файл, то тут дело в постановке задач для них.
Ответ написан
piromanlynx
@piromanlynx
Системный администратор в Perfect Solutions
Используйте puppet/ansible/... и не думайте об этом вообще
Ответ написан
parotikov
@parotikov
Laravel, OctoberCMS, Vue, Nuxt.js)
У себя я делал так:
Был боевой сервер, например, prosto-tak.ru, и дев сервер - dev.prosto-tak.ru
Под каждого разраба заводил отдельный домен, вроде parotikov.dev.prosto-tak.ru
Затем, у разраба был доступ в панель управления (мы использовали vesta cp), где он мог поверх своего именного субдомена строить дальше иерархию: project1.parotikov.dev.prosto-tak.ru, project2.parotikov.dev.prosto-tak.ru
Дальше, если нужно еще детальнее, можно добавить версию релиза, название ветки, etc: feature.project1.parotikov.dev.prosto-tak.ru, service.project1.parotikov.dev.prosto-tak.ru
Да, выглядит немного избыточно, но стоит один раз всем объяснить эту доменную модель, пространство имен, так сказать, и все становится очень стройно.

Нагрузка по созданию собственных субдоменов ложилась на самого разраба, благо там делается все в 3 клика. Кому надо - тот и создает себе нужную структуру, а лишнего ничего у него не дублируется.

В разговоре вообще очень просто: говорит тебе Пупкин - открой сайт с веткой branch55 на третьем сервисе. И ты открываешь branch55.service3.project1.pupkin.dev.prosto-tak.ru. А локально у себя, чтоб каждый раз не вбивать длинный урл, можно и в hosts алиас повесить.

P.S: Но если это массово, то лучше какой-нибудь дирижер типа ansible с шаблонами использовать.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы