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

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

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

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

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

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

Иван Артамонов: с ДНС есть проблема если тестировщики внешние и у них 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 (при наличии расписанных хотелок ) для формирования системы разработки, и конечно разрешение сверху :)

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

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

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

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

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

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

Иван Артамонов: вебсервер всегда резолвит домен в определенную директорию. Поэтому вам не нужны домены на тестовой машине. Нужно просто каждую ветку собирать в отдельной директории на тестовой машине и вместо 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'е, который будет каким-то образом понимать, что если это тестовый сервак, то первый сегмент урла, это всегда ветка и ее нужно добавить в базовый урл... Т.е. без костыля никак... Я прав? Или я чего-то не знаю?

Иван Артамонов: не работал, у нас если кто-то желает потестить руками, он может выкачать ветку себе на дев машину и делать это там. По поводу относительных урлов, нужно просто начальный слеш убрать 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 рабочие фичи. Так как у нас все в одной ветке. Тестить нужно разные фичи в разных ветках, и после тестирования сливать в мастер, который потом пойдет на прод. А не сливать все в мастер, а потом тестить. Так что тоже не получается...

Иван Артамонов: почему ? если у вас 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.. как-то так )

Иван Артамонов: вы ошибаетесь. Полный 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.

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

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

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

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. Ваша проблема в том, что вы сами же придумали себе проблему, а теперь пытаетесь героически её решить.

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

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

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

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

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

Илья: А при чём тут 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 как основа для доменов, а не разрабы.

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

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

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

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