Как правильно настраивать дев-окружение для веб-разработки?
Не думайте о доменах. Вы смешали администрирование и программирование. Не нужно никакого 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 и продакшн сервера. Примерно так в общих словах устроена веб разработка.
У себя я делал так:
Был боевой сервер, например, 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 с шаблонами использовать.