Комментарии 36
rsync?
Честно говоря, не понял как rsync может помочь автоматизировать работу? Да и нагрузка боюсь излишняя будет на production'е
Есть мнение, что раз при рассылке после commit скрипт знает, какие файлы были обновлены, то он может каким-то образом узнать ещё и текст комментария, и в зависимости от него произвести какое-то действие. Пока больше в эту сторону смотрим.
Есть мнение, что раз при рассылке после commit скрипт знает, какие файлы были обновлены, то он может каким-то образом узнать ещё и текст комментария, и в зависимости от него произвести какое-то действие. Пока больше в эту сторону смотрим.
думаю вся ваша беда в смешении понятий. SVN управляет версиями. Имеет средства получения "копий" проекта. А уж ваша задача самим определить куда, и при каких действиях эти "копии" должны выкладываться. Напишите пару скриптов которые будут получать "ревизии" и rsync их на production (в них же определение зависимостей и выкладывания нужных библиотек).
Либо как вариант, сделать checkout на prod-сервере, а потом каждый раз, когда надо, делать svn update.
Копайте в сторону хуков.
В данный момент используем posc-commit хук, на котором производится update на на document_root апача, установленного на dev-сервере. Делать каждый раз update на production признали нецелесообразным. Нужно ввести какой-то логический момент или вообще как-то с другой стороны взглянуть =\
А почему так признали?
Просто доверять апдейт продакшн сервера автоматике стремновато..
Да и неужели так часто надо что то закоммитить, так что бы оно сразу появилось на продакшене?
Просто доверять апдейт продакшн сервера автоматике стремновато..
Да и неужели так часто надо что то закоммитить, так что бы оно сразу появилось на продакшене?
Делать отдельную ветку для продакш сервера. И делать на продакш тоже самое, но уже по этой ветке.
НЛО прилетело и опубликовало эту надпись здесь
мде...
1. Stable версия живёт в TRUNK
2. Dev версия живёт в ветке(ах) — после обкатки оно сливается в TRUNK
3. На production системе просто делаем по-необходимости svn up — тут правда надо учитывать что порой надо проводить апдейт структуры СУБД, для этого у всех свои подходы. У нас автоматизированый скрипт всё делает из Хуков
1. Stable версия живёт в TRUNK
2. Dev версия живёт в ветке(ах) — после обкатки оно сливается в TRUNK
3. На production системе просто делаем по-необходимости svn up — тут правда надо учитывать что порой надо проводить апдейт структуры СУБД, для этого у всех свои подходы. У нас автоматизированый скрипт всё делает из Хуков
Ну а загрузка из TRUNK на продакшн проходит исключительно по расписанию?
Просто хотелось бы дать возможность программистам самим делать апдейт на продакшн, причём желательно чтобы этот апдейт происходил только из репозитория, иначе всё-равно появятся исправления "по живому" и тп.
Просто хотелось бы дать возможность программистам самим делать апдейт на продакшн, причём желательно чтобы этот апдейт происходил только из репозитория, иначе всё-равно появятся исправления "по живому" и тп.
давать право апдейтить продакшн всем программистам — глупо :) плавали, знаем
должен быть development head кто это делает когда возникает такая необходимость... у нас обычно обновления выкатываются в воскресенье ночью, и это после нескольких недель тестирования на демо-системе... и всё равно в live порой попадают косяки
апдейт должен происходить исключительно из репозитория. никаких фтп и прочих
должен быть development head кто это делает когда возникает такая необходимость... у нас обычно обновления выкатываются в воскресенье ночью, и это после нескольких недель тестирования на демо-системе... и всё равно в live порой попадают косяки
апдейт должен происходить исключительно из репозитория. никаких фтп и прочих
В качестве системы контроля версий вам подойдет svn или git. Я бы рекомендовал git.
Для деплоя используйте capistrano - он на ruby и заточен под rubyonrails, но без труда можно использовать для деплоя чего угодно.
Для деплоя используйте capistrano - он на ruby и заточен под rubyonrails, но без труда можно использовать для деплоя чего угодно.
хз в чом проблема оО
У нас например git, а не svn, но все равно. Есть две ветки master (самая последняя) и release (продакшн версия). Баги мы комитим в обе ветки а новый функционал только в мастер, а потом просто мержим. + Есть два разных сервака на один(боевой) деплоим релиз бранч на другой(тестовый) мастер. Для деплоя используется capistrano (для пхп если нет деплойщиков можно свой простенький скрипт написать). В итоге все сводиться к 3-4м простым действиям
checkout нужный бранч
git commit -a
git push
cap stable/develop deploy.
И все! В чем у вас то проблема?
У нас например git, а не svn, но все равно. Есть две ветки master (самая последняя) и release (продакшн версия). Баги мы комитим в обе ветки а новый функционал только в мастер, а потом просто мержим. + Есть два разных сервака на один(боевой) деплоим релиз бранч на другой(тестовый) мастер. Для деплоя используется capistrano (для пхп если нет деплойщиков можно свой простенький скрипт написать). В итоге все сводиться к 3-4м простым действиям
checkout нужный бранч
git commit -a
git push
cap stable/develop deploy.
И все! В чем у вас то проблема?
мы делаем так:
1) пишем и коммитим в trunk на dev сервере
2) когда исправляем баг оставляем в trac'e все файлы которые изменили
3) ведущий программист или начальник выкладывает на production сервер эти файлы
4) если что-то не так и идет баг дальше или другой, откатываемся назад.
в этой системе не удобно только то, что приходится вручную писат все измененные файлы. но максимальный список был в районе 15 файлов. обычно 3-4. автоматизировать не знаю как
1) пишем и коммитим в trunk на dev сервере
2) когда исправляем баг оставляем в trac'e все файлы которые изменили
3) ведущий программист или начальник выкладывает на production сервер эти файлы
4) если что-то не так и идет баг дальше или другой, откатываемся назад.
в этой системе не удобно только то, что приходится вручную писат все измененные файлы. но максимальный список был в районе 15 файлов. обычно 3-4. автоматизировать не знаю как
Я на своём хосте, обычно делаю так:
для перезаписи документов, вам нужно будет использовать ключ --force
Ну а если у вас из проекта будут удаляться/переименновываться файлы/папки, то по уму будет сделать сперва checkout проекта, и потом update
svn export http://..../trunk/ ~/public_html/для перезаписи документов, вам нужно будет использовать ключ --force
svn export --force http://..../trunk/ ~/public_html/Ну а если у вас из проекта будут удаляться/переименновываться файлы/папки, то по уму будет сделать сперва checkout проекта, и потом update
Наша контора мочит на java и использует svn, поэтому есть свои нюансы, но в общих чертах устроено так:
1. текущая версия разрабатывается в trunk
2. предыдущие релизы копируем в branch, например 1.0, 2.0.
3. config-manager делает сборки, полностью автоматизированные, изменяя только ревизию, версию и окружение (для каждогог сервера храняться свои конфиги, которые подменяются). Скрипты написаны на ant. Этот скрипт в ходе сборки делает в tags копию по ревизии сборки, и назыывает ее по порядковому номеру сборки, например 1.0.1, 1.0.2 и тд.
4. этот же скрипт автоматически деплоит приложение на тестовый сервер, ну или в вашем случае на production, хотя это можно делат и руками.
1. текущая версия разрабатывается в trunk
2. предыдущие релизы копируем в branch, например 1.0, 2.0.
3. config-manager делает сборки, полностью автоматизированные, изменяя только ревизию, версию и окружение (для каждогог сервера храняться свои конфиги, которые подменяются). Скрипты написаны на ant. Этот скрипт в ходе сборки делает в tags копию по ревизии сборки, и назыывает ее по порядковому номеру сборки, например 1.0.1, 1.0.2 и тд.
4. этот же скрипт автоматически деплоит приложение на тестовый сервер, ну или в вашем случае на production, хотя это можно делат и руками.
Правильно я понимаю, что лучшим решением будет размещение на продакшн-сервере скрипта, который (запросив логин и пароль конечно) будет делать чекаут и апдейт из репозитория?
А что посоветуете делать, если вместо production сервера имеем виртуальный хостинг без шелла?
Не хочу показаться снобом, но советую поискать более приличный хостинг.
Да у меня то как раз есть приличный хостинг, просто бывает такое, что сайт должен быть размещен на хостинге заказчика (у меня сейчас именно такая ситуация).
Может все-таки существуют решения, позволяющие залить с репозитория обновления по фтп на продакшн-сервер (или с машины клиента, когда делается commit)?
Может все-таки существуют решения, позволяющие залить с репозитория обновления по фтп на продакшн-сервер (или с машины клиента, когда делается commit)?
Как с этим справляются в Яндексе:
http://softwaremaniacs.org/blog/2007/08/…
Со своего опыта: Организуйте четкий процесс выделения релизов в теги.
А еще советую разобраться с ant или maven, чтобы не возится с упаковкой и деплоем рукамию
http://softwaremaniacs.org/blog/2007/08/…
Со своего опыта: Организуйте четкий процесс выделения релизов в теги.
А еще советую разобраться с ant или maven, чтобы не возится с упаковкой и деплоем рукамию
Не надо svn, у вас будет немеряно гемороя с мержем. Берите сразу какой-нибудь git...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как использовать SVN при разработке Web-сайтов?