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

Question

[Иван Артамонов]

Привет всем! Ребят, подскажите какие-то 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 сказать тестеру или менеджеру, зайди ко мне посмотри оно работает. "зайди ко мне" имеется ввиду открыть его дев в браузере. Знаю что можно сделать своей ДНС сервер и для каждого сотрудника в компании по его айпи направлять его в нужную папку на сервере, хотя в браузере у всех будет один адрес. Но кажется что это слишком сложно. Может есть еще какие-то варианты... Как вообще люди это делают нормальные?

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

Кто решал подобные задачи, поделитесь советом, плз.

Comments

[s5656]

А как вы раньше вообще работали? Вроде написано, что PHP-Developer...

Answer 1

[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 и продакшн сервера. Примерно так в общих словах устроена веб разработка.

Comments

[sulla]

>>Разработчикам не нужен никакой dev сервер.

Окэй, а как тогда отлаживать оплаты/платёжые гейты ?
ни яндекс, ни робокасса не работает локально. Заглушки писать каждый раз ?!

[AlexanderY]

sulla: ИМХО, "дев-сервер" нужен, но один на всех. У вас же один проект? Один продакшн, и должен быть один тестовый сервер, на котором вы будете обкатывать платежки и какие-то еще фичи, которые не обкатаешь на локальном хосте. Собственно, тут прозвучало "stage-сервер", вот берем это самое, но настраиваем доступ извне на время тестов платежек и прочего. Ну или на всё время, это уже детали.

[sulla]

AlexanderY: тогда что делать в ситуации когда на staging выкачен текущий релиз и его активно гоняет тест команда? а задачу с платежами надо делать и отлаживать.
не надо трогать staging оно вообще отдельно от dev сервера существует.
А один общий дев более чем на 2х программистов - по опыту, не рабочий вариант.

[Иван Артамонов]

sulla: Похоже вы меня как раз понимаете. Я вот тоже как-то внутренне не могу принять идею, что разработка у каждого разраба идет локально. Мало ли какое он там себе окружение сделает, не ту версию PHP поставит или еще что... но и не это главное. А главное, что есть вещи, которые реально должны работать на сервере. Это могут быть и не только платежки, но и всякие API. И более того. Тестеров тоже несколько. Допустим три тестера, тестят три разные задачи трех разных разрабов. И все эти три задачи находятся в трех разных ветках. Как это сделать на одном тестовом серваке? Я работал в компании, где был свой днс, и у каждого тестера/разраба была своя папка на сервере, в которой он ставит нужную ветку. Но домен у всех был одинаковый, ты просто по айпи резолвился именно в свою папку. И получается, что было 20 человек в команде, и 20 физически разных папок на сервере. Но не было кучи разных доменов, типа если есть несколько сервисов, субдоменов, то у каждого разраба еще по пять субдоменов и всего 100 доменов получается (20*5). Т.е. из-за своего ДНС доменов было всего 5 одинаковых для каждого разраба, но каждый по факту попадал в свою папку. Надо тебе тестить что-то, включай нужную ветку и ты никому не мешаешь... Я хотел бы найти какой-то подобный вариант организации, но не хочу делать свой ДНС. Я как бы не сисадмин и просто не смогу его настроить..

[sulla]

Иван Артамонов: с ДНС есть проблема если тестировщики внешние и у них ip не постоянные.

На самом деле нет проблемы в локальной разработке, крути и делай что хочет - весь код всё равно проходит через test сервер и/или staging, рельсы вон по умолчанию локально отлично работают и отлаживаются.

Иван, не понял про сисадмина - а зачем им Вам быть?
В принципе всё реализуется скриптами запущенными по крону или через jenkins при деплое.

надо только определиться, что и как нужно:
1 сделать сборку для дев сервера (со всеми нужными хостами для разработки) те для каждого разработчика свой вирт сервер с настроенными хостами и 4 уровенем url

2 собрать выкатку на тест:
2.1 отдельной ветки [branch].service1.company.com
2.2 RC для [rc-branch].service1.company.com (c группой веток из 2.1)
2.3 выкатку на staging/pre-prod c полубоевой БД [staging].service1.company.com

и да Вам скорее всего нужен Админ ) часов на +/- 8-40 (при наличии расписанных хотелок ) для формирования системы разработки, и конечно разрешение сверху :)

а да и не забываем про БД :
- для дева (в принципе всем разрабам достаточно одной, хотя тут есть нюансы если добавляется новый функционал который зависит от БД или удаляются данные - один сломал, остальные бамбук курят)
- для стэйджа (обезличенную прода, для тестов на нагрузку и объёмы)

Про кэши, рэбиты и тп - всё же это тоже дублируем для каждого

[xfg]

Иван Артамонов: чем вас не устраивает вариант, после коммита в удаленную ветку автоматически собирать билд в директории с названием ветки, тогда ветка my-cool-feature будет доступна по адресу http://ip.add.re.ss:port/my-cool-feature ? Зачем вам нужен какой-то треш с доменами?

[AlexanderY]

sulla: я вам "гениальную" мысль скажу, от ваших частных кейсов и отталкивайтесь. Я сделал предположение, что "платежные" задачи все же не отличаются на продакшене, стэйдже и прочем тестовом окружении. Если у вас не так - да, придется делать что-то уникальное. В конце концов, можно выкатить отдельный сервер только для теста платежек. А потом его убить, когда всё протестируете.

Иван Артамонов: разные версии php и прочего у разрабов не будут, если юзать какой-нибудь простейший Vagrant или аналоги. Прелесть в том, что у всех будет одинаковая среда. Вообще, дельные варианты предложили, буду рад потом прочитать статью на Хабре о том, как вы все организовали :)

[Иван Артамонов]

xfg: Ну а если одному тестировщику нужно тестить одну ветку, а другому таску из другой ветки. Как они будут на одном домене тестить? Или например другой кейс. Для картинок у нас специальный сервер img.company.com или даже несколько img1, img2.company.com etc... в html генерятся абсолютные ссылки. Для дева у нас должен быть некий img.company-dev.com. Но если на серваке в один момент времени есть только один виртуальный хост, то не получается. Т.е. как минимум отдельный домен для картинок должен быть... ну и что с тестерами делать, непонятно... в общем, пока непонятно как уйти от треша с доменами... или я просто вашу мысль до конца не понял, простите если туплю...

[xfg]

Иван Артамонов: вебсервер всегда резолвит домен в определенную директорию. Поэтому вам не нужны домены на тестовой машине. Нужно просто каждую ветку собирать в отдельной директории на тестовой машине и вместо branch.company-dev.com будете обращаться как company-dev.com/branch. После коммита в удаленную ветку автоматически собирайте билд проекта в директории с названием ветки и в этой директории у вас будет лежать отдельная копия сайта. Тестировщик заходит на company-dev.com и видит все директории (сборки проекта) существующие на данный момент, щелкает по нужной директории и перед ним открывается сайт, который можно потестить руками. При сносе удаленной ветки сносите директорию с сайтом и копию базы к нему.

[Иван Артамонов]

xfg: Аа.. я понял о чем вы ) Да, так вроде будет работать. А вы работаете или работали подобным образом? Если да, то не доставляет ли проблем то, что ссылки на статику в html должны всегда быть только абсолютными? Т.е. если у нас корень сайта в папке, типа company-dev.com/branch/, то нельзя например сделать картинку с адресом типа src='/img/logo.jpg'. Она тогда будет смотреть в company-dev.com/img и не найдет... та же фигня касается стилей, js и прочего. Нужно чтоб всегда на всей статике были строго только абсолтные урлы. Это в принципе правильно. Но абсолютные урлы конструируются либо динамически исходя из $_SERVER['HTTP_HOST'] либо исходя из какого-то конфига, где указан базовый урл. Базовый урл в разных ветках в конфиге не может быть разный. А в $_SERVER['HTTP_HOST'] лежит домен, а следующая за ним папка это просто сегмент урла. Нигде в глобальных переменных сервера ее отдельно нет, насколько мне известно. Нужно писать какой-то костыль в своем URL Mapper'е, который будет каким-то образом понимать, что если это тестовый сервак, то первый сегмент урла, это всегда ветка и ее нужно добавить в базовый урл... Т.е. без костыля никак... Я прав? Или я чего-то не знаю?

[xfg]

Иван Артамонов: не работал, у нас если кто-то желает потестить руками, он может выкачать ветку себе на дев машину и делать это там. По поводу относительных урлов, нужно просто начальный слеш убрать src='img/logo.jpg'. По поводу абсолютных и динамических нужно позаботиться и сделать так, чтобы оно работало как на дев машине, так и на тестовой и на продакшн. Скорее всего вам нужно будет запускать приложение в нескольких окружениях типа dev, test, prod и каждому рассказать как собирать абсолютные урлы. Это в любом фреймворке есть. Но как сделать наилучшим способом, я не знаю, думать нужно :)

[Виктор Дидицкий]

xfg на мой взгляд идея с папками просто жесть. Множество лишних копий, проблемы с линками. А как показывает практика, после мерджа в основную ветку что-то может поломаться. Получается тестерам придется тестить сначала на ветку разраба, потом общую ветку, и только потом выдавать в прод.
Иван Артамонов Все намного проще: собираете дев версию на докере(в идеале) или на вагранте. Каждый разработчик получает локальную версию, которою пилит, ломает. И конечно то, что сделал разраб(свою задачу) он должен потестить сам. После чего все поделки через пулл-реквесты сливаются в дев ветку, которую уже тестят тестеры. Если что-то не работает, разрабы выпускаю фиксы. После чего на работоспособную версию ставится тег и она летит в прод. Это минимальны вариант, без всяких CI, CD, автотестирования, и автосборки

[Иван Артамонов]

xfg: если убрать слеш, то на странице например company.com/branch/catalog/product/1 картинка будет искаться в папке branch/catalog/product/1, которой не существует...
GhostSt92: про локальные копии - ок, но что касается тестирования, не понятно. Если каждый разраб пилит свою фичу в какой-то своей локальной ветке, а потом все разрабы когда оно у них готово сливают это в одну дев-ветку на сервер, то получается что в этой дев-ветке одновременно несколько разных непротестированных фич. И как быть если из 3х фич, например 1 работает, а две оказались с багами? Мы не можем вылить это одну фичу изолировано. Мы должны ждать пока пофиксятся оставшиеся 2. А в это время пока 2 фиксятся, тот чувак, который запили первую фичу нормально доливает следующую. И получается что 2 пофиксились, которые были с багами, но теперь на сервере уже 4 фичи, 3 работают, а в одной последней - баг. И снова... мы не можем вылить изолировано 3 рабочие фичи. Так как у нас все в одной ветке. Тестить нужно разные фичи в разных ветках, и после тестирования сливать в мастер, который потом пойдет на прод. А не сливать все в мастер, а потом тестить. Так что тоже не получается...

[xfg]

Иван Артамонов: почему ? если у вас 1 точка входа index.php, то на любой странице картинки будут искаться относительно директории где лежит index.php.

[Виктор Дидицкий]

Иван Артамонов, master это продакшен ветка, туда попадают только оттестированные фичи. Для описанного вами кейса существуют релизные ветки. Работает это так. У вас в dev 3 фичи, из них одна рабочая. Из dev ветки создается release/1.0. Все новые фичи идет в дев ветву. Разрабы фиксят баги и сливают их в release/1.0. Когда все баги пофикшены, release/1.0 сливается в master и выкатывается на прод. Это стандартный Git Flow. Баги с прода создаются от мастер ветки и сливаются и в master, и в dev. Также нужно после каждого фикса в release/1.0, сливать его в дев. Можно настроить автомердж. Хотите выкатить новую версию - создаете release/1.1 из dev и все по новой

[Иван Артамонов]

xfg: Вообще-то нет :) проверьте ) например картинка src='logo.jpg' на странице domain.com/catalog/product будет искаться в папке catalog. А если еще после product поставить слеш, то в папке catalog/product и точка входа index.php тут не причем. Картинку ищет браузер. Браузер не в курсе вашей логики резолвинга урла, которая у вас спрятана в index.php.. как-то так )

[xfg]

Иван Артамонов: вы ошибаетесь. Полный url это domain.com/index.php/catalog/product и всё что после index.php это не папки, а обычная строка, так называемый роут. Картинку ищет не браузер, а веб-сервер и делать он это будет относительно той директории, которую вы ему укажите для домена domain.com. Если у вас

server {
server_name domain.com;
root /home/www/domain;
...
}

то src='logo.jpg' это /home/www/domain/logo.jpg всегда независимо, что у вас написано после index.php.

[xfg]

GhostSt92: согласен, что жесть. Но вы же сами видите, что автору зачем-то нужно чтобы все ветки были доступны с удаленной машины, чтобы тестеры ходили по ним своими браузерами и что-то там тестили и другие варианты он принимать не желает. Я уже не однократно писал человеку, что разработчик сам тестирует фичу и что если уж автор хочет что-то там тестить руками или как-то еще, то может master выкатывать не сразу на prod, а не stage и делать это там.

[Виктор Дидицкий]

xfg: к сожалению вижу. Поэтому я описал рабочий вариант, не вдаваясь в бессмысленный спор. А автор сам сделает выводы - сейчас или позже. Я тут недавно прочитал вопрос человека, что-то вроде "как начать использовать гит в проекте". И в комменте тот автор писал что программисты не хотят гит, у них и по ftp все хорошо работает. Поэтому я не сильно удивляюсь этому решению. Радует другое - человек ищет решение. Не примет волевое решение изменить флоу сейчас - вернется к вопросу когда будет 6 разрабов, и терпеть эти костыли станет не вмоготу.

[Иван Артамонов]

xfg: блин, ну index.php обычно убирают из урла.. о чем мы спорим.. вот вам скрин, неужели такое нужно доказывать... https://yadi.sk/i/BXzok4se3GKemm

[Иван Артамонов]

xfg: и кстати вариант "разраб сам тестит свой функционал" к сожалению не подходит... зачем тогда тестеры... и да, "автору зачем-то нужно" чтобы тестили тестировщики, и зачем-то нужно чтобы могли работать сразу два или три тестера над двумя разными фичами, которые находятся в двух разных ветках и не слиты в одну... странно, что вам непонятно зачем это нужно... я честно ценю, что вы пытаетесь помочь. спасибо, но в вашем предложении есть нюансы, которые мне либо непонятны, либо не подходят... что тут еще скажешь )

[xfg]

Иван Артамонов: index.php не убирают, а скрывают, но в любом случае все урлы по которым физически на сервере ничего не существует, он редиректит на точку входа index.php, который лежит в корне. Соответственно, какую страницу сайта вы бы не открыли, ваш current path всегда будет равен директории где лежит index.php т.к все страницы вашего сайта динамические и физически их не существует на сервере (они все генерируются через index.php). Соответственно на любой динамически сгенерированой странице сайта (через index.php) все ассеты будут резолвиться относительно этого current path. Я мог бы вам показать, что именно так это и работает и я уверен в этом на 100%, но мне лень тратить своё время и разворачивать для вас демо, чтобы что-то вам доказать. Достаточно понять, что ваш веб сервер всегда обращается к файлу index.php, какую страницу сайта вы бы не открыли, если у вас одна точка входа, незвисимо от того, видите ли вы index.php в урл или нет. И соответственно все картинки без начального слеша будут отдаваться относительно директории того файла, к которому вы обратились, а это index.php для любой страницы вашего сайта.

Про тестеров я вам уже не раз писал. Если у вас есть специально обученный человек, которому не жить как приспичило тестировать каждую ветку в отдельности, то он может скачать эту конкретную ветку себе на дев машину и делать там всё, что он хочет не заморачивая голову остальным. Но вообще в крупных компаниях тестировщики работают не так, они плевать хотели на все эти ваши ветки, они ничего в них не понимают. У них есть чек-листы и именно по ним они проверяют конкретный билд, который собирается выйти в релиз. Это не ветка и не одна фича, это то, что уже реально готово выйти на продакшн как next version. Если тестеры заворачивают этот билд, то разработчики правят то, что тестировщиков не устраивает и выкатывают новый билд. И для таких вещей есть stage. Ваша проблема в том, что вы сами же придумали себе проблему, а теперь пытаетесь героически её решить.

На этом всё. В дальнейшую дискуссию не вступаю, поскольку мне больше нечего сказать, по вашей теме.

Answer 2

[Илья]

Развернуть GIT?

Идеальной на мой взгляд будет схема:

• [branch].company.com
  
• [branch].service1.company.com
  

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

P.S. как по мне, если разработчики правят один и тот же файл, то тут дело в постановке задач для них.

Comments

[Иван Артамонов]

git у нас есть. Вопрос в субдоменах, разных папках и вир.хостах, которые нужно добавлять. Как git от этого избавит? Может я чего-то не знаю? )

[Илья]

Иван Артамонов: как минимум он уменьшить количество. Допустим у вас будет 5 разрабов, а в работе 2 фичи для основного сайта и один фикс для service1. Таким образом у вас должны быть ветки: [dev|feature1|feature2].company.com и [dev|fix1].service1.company.com. Я думаю 5 доменов, вместо 10 неплохое сокращение. Да и к тому же это позволит вам понимать, что происходит на том или ином домене.

Ну а поповоду доменов ru, fr, ... если физически один и тот же сервер, то проблем нет. Если нет, то стоит задуматься, чтобы это был один и тот же сервер.

[Илья]

Иван Артамонов: а по поводу создания поддомена для ветки git - то я думаю небольшой sh скрипт сократит эту задачу до одной команды.

[sulla]

Илья: А при чём тут git то ? это же схема деплоя по сути, а не разработки-отладки

Иван Артамонов описанная Илья схема потребует введения в работу, к примеру Jenkins,
и вся работа будет строиться примерно так:

1 разработчик делает локально задачу, запиливает её в кокретной ветке
2 разработчик сдаёт её в тестирование
3 тестировщик в Jenkins выбирает ветку и сервер (или сервис) куда её выкатить
4 Jenkins выкатывает ветку на сервер, параллельно создавая субдомен [branch].service1.company.com или [branch].company.com
5 тестируется
6 прошло тест - ветка вливается в текущий релиз
7 ветка [branch] , субдомен и все зависимости убиваются тем же Jenkins

Тут правда есть пара моментов:
1 надо следить за зависимостями тк при деплоее [branch] на company.com он куда будет смотреть в [branch].service1.company.com или в [branch-old].service1.company.com
2 при удалени ветки и субдомменов - надо так же следить за зависимостями сервисов
Но по идее всё это решается на стадии внедрения и 1 раз )

[Илья]

sulla: Git как основа для доменов, а не разрабы.

Answer 3

[Михаил Конюхов]

Используйте puppet/ansible/... и не думайте об этом вообще

Answer 4

[Николай Паротиков]

У себя я делал так:
Был боевой сервер, например, 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 с шаблонами использовать.

Comments

[Илья]

А зачем городить поддомен на ветку и на разраба? Если веткой занимается несколько человек у всех будет отображаться одно и то же, логичнее тогда домен на ветку делать, или какие-то подводные камни есть?

[Николай Паротиков]

Илья: менеджер или любопытный может попасть на сайт в момент мержконфликта, ветвления, и т.д. Ну и пространство имен же.
Если веткой занимается несколько человек в одной папке (читай домене) — это какой-то неправильный гит.

[Иван Артамонов]

Выглядит слегка по-деревенски, но по факту самое реальное решение, как по мне... по сути это тоже самое, что у нас сейчас. Только у нас всю эту фигню делает админ, а вы поставили себе панель управления и каждый разраб создает себе нужный ему домен сам никого не напрягая. Единственная реальная альтернатива, которую я пока вижу, это свой ДНС-сервер, который будет резолвить каждого разраба в его папку при том, что домен у всех будет одинаковый. Для того, чтобы зайти на ветку соседа, админ может написать небольшой скриптик и web-страничку, где будет выпадайка с именами коллег. Выбираешь коллегу, нажимаешь "ок" и ДНС резолвит тебя уже в его папку. По тому же самому домену. Имхо, это 2 самых реальных варианта. Причем и у первого и у второго есть свои плюсы и минусы... Пока из всего, что предложили, третьего варианта я не нашел... Спасибо вам за ответ.

[Николай Паротиков]

Иван Артамонов: зачем вам эта магия? Админ может написать... А если заболеет/уволился/в отпуске. Решение в лоб, возможно, но зачем плодить сущности? Все таки у вас не по 10 доменов в день. Вы посчитайте времязатраты там и там, помножте на разрабов, всяко очевиднее будет.