Как использовать SVN при разработке Web-сайтов?

[nini]

rsync?

[Megagertz]

Честно говоря, не понял как rsync может помочь автоматизировать работу? Да и нагрузка боюсь излишняя будет на production'е

Есть мнение, что раз при рассылке после commit скрипт знает, какие файлы были обновлены, то он может каким-то образом узнать ещё и текст комментария, и в зависимости от него произвести какое-то действие. Пока больше в эту сторону смотрим.

[duncanf1]

думаю вся ваша беда в смешении понятий. SVN управляет версиями. Имеет средства получения "копий" проекта. А уж ваша задача самим определить куда, и при каких действиях эти "копии" должны выкладываться. Напишите пару скриптов которые будут получать "ревизии" и rsync их на production (в них же определение зависимостей и выкладывания нужных библиотек).

[nini]

Либо как вариант, сделать checkout на prod-сервере, а потом каждый раз, когда надо, делать svn update.

[Megagertz]

делать его придётся вручную или есть какие-то более интересные способы?

[Stalker_RED]

на продакшене кладете какой-нить checkout.php, а в нем пишете что-то вроде:
файл можно прикрыть hatccess-ом, или сделать формочку с паролем.

[Stalker_RED]

парсер проглотил:
<pre><? system("/var/www/commit.id-ua.sh", $ret); echo $ret; ?>

[Megagertz]

Да, пока что так и сделали, правда ещё до прочтения комментария, но всё же спасибо ;)

[JustLuckyGuy]

Копайте в сторону хуков.

[Megagertz]

В данный момент используем posc-commit хук, на котором производится update на на document_root апача, установленного на dev-сервере. Делать каждый раз update на production признали нецелесообразным. Нужно ввести какой-то логический момент или вообще как-то с другой стороны взглянуть =\

[josser]

А почему так признали?
Просто доверять апдейт продакшн сервера автоматике стремновато..

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

[Megagertz]

Любое исправление багов стараемся сразу заливать на продакшн. Ввиду действительно большого числа сайтов - это происходит по несколько раз в день((

[JustLuckyGuy]

Делать отдельную ветку для продакш сервера. И делать на продакш тоже самое, но уже по этой ветке.

[Megagertz]

Я не понял :( Старался, честно, но не понял.
Тоесть мы делаем ветку и в ней лежит последняя стабильная версия? А как программист сможет инициировать заливку её содержимого на продакшн?

[JustLuckyGuy]

Вы делаете 2 ветки. Одна - стабильная версия (из которой автоматически обновляется продакшн), вторая - рабочая версия (для dev). Как только нужно обновить продакшн - вы перемещаете dev в стабильную ветку.

[clops]

мде...

1. Stable версия живёт в TRUNK
2. Dev версия живёт в ветке(ах) — после обкатки оно сливается в TRUNK
3. На production системе просто делаем по-необходимости svn up — тут правда надо учитывать что порой надо проводить апдейт структуры СУБД, для этого у всех свои подходы. У нас автоматизированый скрипт всё делает из Хуков

[Megagertz]

Ну а загрузка из TRUNK на продакшн проходит исключительно по расписанию?
Просто хотелось бы дать возможность программистам самим делать апдейт на продакшн, причём желательно чтобы этот апдейт происходил только из репозитория, иначе всё-равно появятся исправления "по живому" и тп.

[clops]

давать право апдейтить продакшн всем программистам — глупо :) плавали, знаем
должен быть development head кто это делает когда возникает такая необходимость... у нас обычно обновления выкатываются в воскресенье ночью, и это после нескольких недель тестирования на демо-системе... и всё равно в live порой попадают косяки

апдейт должен происходить исключительно из репозитория. никаких фтп и прочих

[seymour]

В качестве системы контроля версий вам подойдет svn или git. Я бы рекомендовал git.
Для деплоя используйте capistrano - он на ruby и заточен под rubyonrails, но без труда можно использовать для деплоя чего угодно.

[kronos]

хз в чом проблема оО
У нас например git, а не svn, но все равно. Есть две ветки master (самая последняя) и release (продакшн версия). Баги мы комитим в обе ветки а новый функционал только в мастер, а потом просто мержим. + Есть два разных сервака на один(боевой) деплоим релиз бранч на другой(тестовый) мастер. Для деплоя используется capistrano (для пхп если нет деплойщиков можно свой простенький скрипт написать). В итоге все сводиться к 3-4м простым действиям
checkout нужный бранч
git commit -a
git push
cap stable/develop deploy.
И все! В чем у вас то проблема?

[quard]

мы делаем так:
1) пишем и коммитим в trunk на dev сервере
2) когда исправляем баг оставляем в trac'e все файлы которые изменили
3) ведущий программист или начальник выкладывает на production сервер эти файлы
4) если что-то не так и идет баг дальше или другой, откатываемся назад.

в этой системе не удобно только то, что приходится вручную писат все измененные файлы. но максимальный список был в районе 15 файлов. обычно 3-4. автоматизировать не знаю как

[Megagertz]

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

[quard]

я бы не сказал что много изменений, тикеты скапливаются, а потом скопом выкладываются

[ukko]

Я на своём хосте, обычно делаю так:
svn export http://..../trunk/ ~/public_html/

для перезаписи документов, вам нужно будет использовать ключ --force

svn export --force http://..../trunk/ ~/public_html/

Ну а если у вас из проекта будут удаляться/переименновываться файлы/папки, то по уму будет сделать сперва checkout проекта, и потом update

[DimaRad]

Наша контора мочит на java и использует svn, поэтому есть свои нюансы, но в общих чертах устроено так:
1. текущая версия разрабатывается в trunk
2. предыдущие релизы копируем в branch, например 1.0, 2.0.
3. config-manager делает сборки, полностью автоматизированные, изменяя только ревизию, версию и окружение (для каждогог сервера храняться свои конфиги, которые подменяются). Скрипты написаны на ant. Этот скрипт в ходе сборки делает в tags копию по ревизии сборки, и назыывает ее по порядковому номеру сборки, например 1.0.1, 1.0.2 и тд.
4. этот же скрипт автоматически деплоит приложение на тестовый сервер, ну или в вашем случае на production, хотя это можно делат и руками.

[Megagertz]

Правильно я понимаю, что лучшим решением будет размещение на продакшн-сервере скрипта, который (запросив логин и пароль конечно) будет делать чекаут и апдейт из репозитория?

[kronos]

а почему на сервере, а не на клиенте?

[Megagertz]

продакшн сервер является клиентом для дев-сервера? я не прав?

[kronos]

нет. Почему не сделать просто: пишешь у себя на машине в консоли ./php deploy.php stable (или что-нить в этом духе), он конектицо к серваку и делает там svn up?

[Megagertz]

Возможно необходимость наличия интерпретатора php на машине разработчика?
Да к тому же разместить скрипт на сервере банально проще. Если хакнут пароль, то положить сервер конечно не составит никакого труда(

[nayjest]

А что посоветуете делать, если вместо production сервера имеем виртуальный хостинг без шелла?

[kivsiak]

Не хочу показаться снобом, но советую поискать более приличный хостинг.

[nayjest]

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

Может все-таки существуют решения, позволяющие залить с репозитория обновления по фтп на продакшн-сервер (или с машины клиента, когда делается commit)?

[kivsiak]

Как с этим справляются в Яндексе:

http://softwaremaniacs.org/blog/2007/08/…

Со своего опыта: Организуйте четкий процесс выделения релизов в теги.
А еще советую разобраться с ant или maven, чтобы не возится с упаковкой и деплоем рукамию

[a_vasyutin]

Не надо svn, у вас будет немеряно гемороя с мержем. Берите сразу какой-нибудь git...