Разработка с помощью SVN

[filipchuk]

Разработка с помощью SVN

В новом проекте есть необходимость коллективной работы программистов. До этого SVN использовал "для себя", просто как систему backup с возможностью отката, сервер обновлял по старинке (копированием по FTP)
Сейчас такой вариант не подходит, и почитав литературы, хочу реализовать следующее:
1) есть домен проекта project.com
2) создаем поддомен dev.project.com - там будет dev-версия проекта, доступ ограничен по паролю
2) в эту dev-версию делаем SVN-checkout
3) также каждый девелопер делает SVN-checkout себе на локальную машину
4) разработчик пишет функционал у себя на машине (у каждого есть своя локальная копию БД), тестирует его
5) после commit в trunk (соглашение, что в trunk отправляется "рабочий" код) выполняется hook, который делает svn update для dev-версии проекта. Если разработчик работает с веткой, то dev-версия не обновляется, результаты работы видно только на локальной машине
6) результаты работы можно просмотреть уже и на dev-версии
7) на production (project.com) делается svn export, над деталями этой операции еще надо подумать, чтоб минимизировать ручную работу

Собственно вопрос: такая схема в реальной работе 2-4 программистов надо проектом будет удобной/правильной, или есть варианты получше?
Возможно, поддомен надо сделать для каждого программиста, и работать с файлами этого поддомена напрямую (подключив себе по SSH папку сервера), без использования локальной копии на своей машине. Тогда обновления каждого программиста будут видны на его поддомене, после их одобрения будет merge в trunk, а в dev-версии будет делаться update из trunk с помощью hook

 

[Dovg]

Возможно, поддомен надо сделать для каждого программиста, и работать с файлами этого поддомена напрямую (подключив себе по SSH папку сервера), без использования локальной копии на своей машине.

Откючили интернет и вся работа встала ).

У нас почти так же как описано в пп. 1-7, только часто на бранчи создаются отдельные субдомены, т.е. структура такая
trunk.project.domain.ru - основная ветка разработки
newfeature.project.domain.ru - бранч newFeature.

 

[filipchuk]

Первая "грабля по лбу" уже найдена - действительно, без интернета разработка заморожена. Хотя проблем с инетом пока не было (есть резервный канал), но по закону Мерфи будут
По поводу сабдомена для важных (больших, долгих) brunches - это улучшение пункта 5, спасибо

 

[fixxxer]

а что мешает все сделать так, но держать девелоперский сервер в локалке?

 

[filipchuk]

Вы имеете ввиду использовать вариант №2 (отдельные сабдомены для разработчиков, работа напрямую на сервере, без копий на локальных машинах), и если сам сервер в локальной сети, то проблема, озвученная Dovg, пропадает?

 

[fixxxer]

ага

с локальными машинами - сложно может получиться.

вот захотели например memcached или sphinx... всем ставить? а если кто-то под виндой предпочитает работать, то можно и вообще напороться на большие сложности.

все же разработку лучше вести на платформе идентичной продакшену.

 

[filipchuk]

спасибо за ответ!

все равно, необходим будет тестовый поддомен staging.project.com (в этом поддомене будет проверяться функционал уже на машине проекта, заказчики также будут смотреть), после утверждения - выкладка на основной домен проекта

если такой вариант (разработка в локальной сети), то как делать выкладку на сервере заказчика?
Ведь если SVN сервер будет в нашей локальной сети, мы не сможем на staging.project.com делать svn update?

 

[fixxxer]

а зачем?

делать деплой на внешнюю тестовую машину (так же, как на реальный прод).

тут советую такой алгоритм:

1) svn export в tmp, генерируем install.sh
2) если надо - дописываем в этот tmp конфигурацию в соответствии с ид или именем сервера, куда идет деплой и тп.
3) на сервере держим папочки с номерами ревизий, дабы избежать состояния "кто-то зашел на полузалитый файл"
4) копируем это дело в $prefix/$revision_number, ну хотя бы (далее следует копипаста)

   $remote_commands = 'tar xzf - -C ' . $remote_dir . ' && ' . $remote_install_sh . ' && unlink ' . $remote_install_sh;
  $deploy_command = "cd $tmp_dir && $tar_bin czf - . | $ssh_cmd '$remote_commands'";
  shell_exec($deploy_command);

тут у меня install.sh это шелл-скрипт, генерируемый при выкладке, который обновляет docroot на текущую ревизию, делает reload веб-сервера, обновляет crontab, подчищает старые папочки с ревизиями (оставляя последние три) и всякая там специфика.

ничто собственно не мешает сделать у такого скрипта аргумент "номер ревизии" ("тэг", "имя ветки" итд) и выкладывать оттестированную ревизию на прод таким же образом

 

[whirlwind]

filipchuk требования делятся на функциональные и нефункциональные. Определение требований - это самый первый этап. Ответь на вопрос "как лучше", можно только зная требования. А насоветовать тебе тут могут абсолютно что угодно. Каждый совет опирается на уникальный опыт.

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

 

[fixxxer]

кстати если таки нужен доступ с прода на девел можно поднять vpn-туннель

а вообще whirlwind дело говорит, мало ли что у тебя там за проект.

 

[filipchuk]

большое спасибо, буду переваривать информацию
жаль плохо знаком с *nix, было бы значительно легче
===============
есть 2 основных задачи:
1) синхронизация работы несколькоих программистов (с помощью SVN)
2) обновление сервера заказчика, по возможности с минимум ручных действий

По поводу обновления fixxer дал пищу для размышлений, как один из способов, пока я не все понял, но время еще есть
На данный момент надо надо организовать работу разработчиков.
Вариант с одним сервером для всех, с поддоменом для каждого разработчика мне больше все-таки нравится.
Но не уверен, что сможем сделать его в локальной сети, так как надо разобраться с автоматической выкладкой на сервер заказчика (он ведь тоже захочет смотреть результаты, причем ежедневно, вручную это делать нехочется).
Если получится сделать предложенный вариант автоматической выкладки, то дело за малым - настроить сервер в локальной сети. Иначе тогда вариант с работой на удаленном сервере, и обновление тестовой версии будет идти простым svn update (хотя может и там не все так просто)

 

[fixxxer]

http://svnbook.red-bean.com/en/1.5/svn.tour.cycle.html

-~{}~ 22.01.10 13:16:

> автоматической выкладкой на сервер заказчика

варианты

1) деплой по крону или коммит хуку в trunk
2) vpn + svn up по крону или коммит хуку
3) vpn + реверс-прокси в локалку на субдомен для заказчика

 

[filipchuk]

книгу перечитаю, спс

VPN тунель врядли настроим (админа у нас нет пока), тогда выходит вариант "1) деплой по крону или коммит хуку в trunk"

 

[fixxxer]

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

лучше уж нанять, хотя бы не в штат, а по разовому договору + на поддержку.

 

[filipchuk]

согласен, надо будет согласовать с заказчиком