Как вы организуете devel окружение?

Question

[Алексей Сумин]

Здравствуйте, хабражители.
Подскажите пожалуйста, как лучше организовать devel окружение (php проекты), есть много разработчиков и много проектов, все проекты лежат и запускаются на отдельном devel-сервере, СКВ Git.
Сейчас возникло два вопроса:
1. Домены и папки. Сейчас для каждого разработчика есть свой поддомен проекта, например bob.devel.mysite.com. Нужно ли под каждую git-ветку заводить еще поддомен вида t12.bob.devel.mysite.com или лучше переключать ветки в одной папке?
2.Доступ к папкам. Большинство разработчиков сидят на win7, есть mac и ubuntu. Доступ к коду лучше организовывать через сетевые диски используя Samba или у разработчиков должны лежать локальные git хранилища, а на сервер заливать по SFTP?

Comments

[Алексей Сумин]

Вариант поднимать локальный сервер на каждой тачке разработчика всё таки не подходит, лишняя работа по управлению, и всю инфраструктуру поднять не реально.

Answer 1

[rozhik]

У меня организовано следующим образом:
К development серверу есть днс запись вида *.domain.com in A x.x.x.x
Конфиг апача
<VirtualHost *:80> UseCanonicalName Off VirtualDocumentRoot /web/%1/html ServerAdmin [e-mail] <Directory /> ... </Directory> </VirtualHost>

В каталоге /web любой из разработчиков может создавать папки. Сколько ему нужно серверов, и под какие цели — решает сам. Периодически скрипт просит разработчика «почистить» лишние, если у него их больше 5ти. Аналогично для nginx.
Соответственно разработчик сам выбирает ответ на вопрос 1.

К папке /web открыт доступ через sftp, samba. По второму вопросу большинство предпочитают доступ по samba или sshfs (тоесть редактируюют код в основном непосредственно на сервере).

Итого:
Каждый разработчик волен решать как ему нравится. Но, есть полиси с рекомендованым подходом (оно большое).

Comments

[Alexander]

Без репозитариев? Сразу же на дев сервере? А если срочно нужно откатить назад или была ошибка и тупо не помнишь, что и где правило до символа?

Раньше когда писал код без репозитариев (git/svn/hg), то бывали ошибки когда к примеру перезаписывал не тот файл, а исходной версии под рукой нету. Или когда спустя время выползала ошибка, которая в коде который я активно писал или правил более месяца назад. И вспомнить что же я там накодил тогда, было сложно. А рабочий сервер мог лежать. Ну или дев.

[rozhik]

Конечно с репозитариями. У нас как правило каждый проэкт живет в нескольких репозитариях, часть может быть на SVN, часть на git. Без VCS ничего никто не пишет. Сервера у нас не лежат. Даже у дев сервера 99.99% uptime.
На рабочих машинах разрабатывать не реально — особенно с терабайтными базами итп.

Answer 2

[Сергей Протько]

Нууу как это сделано у большинства:
у разработчика есть локальная копия репозитория (иначе зачем вам git), и он пишет все у себя локально. Локально интегрирует код других девелоперов со своим ну и т.д. То бишь разработка исключительно локально.

Сервер только один, выкатывать туда можно либо на прямую из git (скажем в gitlab можно добавить доступ по ssh только на чтение) и пулить туда мастер. По сути на сервере всегда должна быть стабильная версия кода, мол с уже заимплеменченными фичами. ну или можно собирать билд в ci по пушу и автоматически разворачивать его.

Comments

[Алексей Сумин]

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

[Alexander]

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

По сути да.
Только, у вас дев(тестовый) сервер? То есть то что не в продакшене, а только для обкатки на сервере или показу третьих лиц?
Если да, то никаких проблем в этом не вижу. Разработчик пишет код, при каждом значимом изменении, а не только поменял кавычку, делается коммит и пуш. Или только коммит.
Это нужно в первую очередь для того, что если что-то пошло не так, всегда можно отмотать одной командой, всё назад, на несколько коммитов. Очень удобно. Не приходится ломать голову, что же я там написал, от чего сломалось. Таким образом быстрый откат на несколько коммитов на сервере. Потом дебаг локально последних изменений, в поиски ошибки. Далее новый коммит на сервер репозитария. И на сервере сайта уже пулл.
Так же по коммитам, видно что же было накодено и в каких файлах. То есть быстро отследить какие были внесены изменения и найти причину ошибки.

[Сергей Протько]

интенсивная откладка/дебаг обычно происходят локально. Если же баг воспроизводится только на сервере, а такое бывает крайне редко, делается отдельная ветка, делается много много коммитов и потом, когда бак пофикшен просто все сквошится в один коммит и переносится в мастер.

Для унификации окружения можно юзать вагрант.

[rozhik]

Этот подход с локальными машинами быстро загибается на больших проэктах.

[Алексей Сумин]

у нас devel — это сервер для разработки, т.е. выполняется код только там, на локальной тачке веб-сервера нет, отсюда необходимость в интенсивном трафике с тачки разработчика на devel. Работа через сетевой диск в таких условиях кажется самой простой, но дошли слухи, что гит очень сильно теряет в производительности на них.

[Сергей Протько]

rozhik, не могли бы вы пояснить? Как-то же люди живут и без этих извращений с сетевыми дисками и т.д. Добиться того, что у каждого разработчика будет одинаковое окружение достаточно просто. Интегрироваться разработчики тоже могу достаточно часто через GIT. Что еще нужно?

[Сергей Протько]

С базами все понятно, но опять же это не такой частый кейс. Да и базу можно держать на отдельном сервере.

[rozhik]

rozhik, обьясняю:
0. Вы наверное не сталкивались со словом сборка…
1. администрировать десятки машин разработчиков это…
2. когда нужно показать промежуточный результат в наружу — не проблема. (доступа к к машинам разработчика снаружи нет)
3. когда ключей лежит вагон.
и много других причин. Вообще есть цепочка:
local -> devel -> staging -> pre-production -> production.
local — никого не волнуеи, показать никому нельзя.
develN — можно показывать статус, давать на предестирование
staging — тестеры его проверяют, обновить не каждый разработчик может
…

[Сергей Протько]

0) сборка проекта вынесена в CI сервер (прогон тестов включен), который и занимается всей рутиной.
1) vagrant. Настроить базовое окружение и юзать его всем членам команды. Это не работает только в очень редких кейсах.
2) для этого есть devel и develN сервер, на который все изменения деплоятся автоматически по пушу в репозиторий (дальше по ступенькам уже вручную идет запуск процесса деплоя)
3) вот тут не понятно. Лично у меня нету проблем ни с ключами ни с сертификатами.

Answer 3

[Александр A]

1) только bob.devel.mysite.com

код и гит репа — локально. в иде (пхпсторм) настроена авто-синхронизация с той папочкой на сервере
т.е. весь код локально, гит локально, ветки переключаются локально, а F5 делается на bob.devel.mysite.com

такая схема позволяет не париться над окружением у себя на компе, особенно если оно требует много чего (у нас например и rabbitmq и mysql и postgres, и еще mongo была) + у всех разработчиков одинаковое окружение для запуска кода, что тоже немаловажно (помогает избежать «а у меня всё норм работает)

Answer 4

[FanatPHP]

Мне сложно понять эту проблему, поскольку сам я сижу под осью того же семейства, что стоит на боевом.
Так что, в моем понимании, девел-сервер — это не единственное место, где программист может запустить написанный на локальном компе код, а сервер, максимально приближенный к боевому, для окончательной обкатки и показа всем причастным к задаче лицам.

Соответственно, разумная организация представляется мне такой
1. Разработчик разрабатывает на своей локальной машине. Именно разрабатывает — пишет, запускает, отлаживает. Разработанное заливает в Git
2. На devel-сервере реализовано динамическое создание поддоменов. Создал девел папку t12 в /opt/www/bob — автоматически появился сайт t12.bob.devel.mysite.com.
3. Делаем в этой папке git clone (или pull) — и таким образом обновляем код.

Comments

[Алексей Сумин]

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