Comments 62
Экономить трафик на сжатии в архив нет необходимости — обхожусь одной командой
ssh exaple_host.com «svn --force --username=export_user --password=export_password export https://example.com/svn/project/ /project/dist»
ssh exaple_host.com «svn --force --username=export_user --password=export_password export https://example.com/svn/project/ /project/dist»
это только в том случае если на сервере есть svn
Так же часто бывает необходимо, перед выгрузкой, произвести над кодом некоторые манипуляции, например удалить тесты (которые на продакшене не нужны), изменить парметры конфигов.
Еще одно приемущество подобного подхода, это простота реализации отката до предыдущей версии, в случае непредвиденной ошибки.
Так же часто бывает необходимо, перед выгрузкой, произвести над кодом некоторые манипуляции, например удалить тесты (которые на продакшене не нужны), изменить парметры конфигов.
Еще одно приемущество подобного подхода, это простота реализации отката до предыдущей версии, в случае непредвиденной ошибки.
С наличием svn на сервере проблем нет.
Проблема разных конфигов для дев версии и продакшена решаю отсутсвием конфига в svn :) app.conf.example, а при установке переименовываю и правлю под конкретную среду. В случае если должны изменится сами конфиги можно руками сходить и подправить.
С откатами на старые версии действительно есть проблема в виде не удаленных файлов от новых ревизий. «rm -rf $DOC_ROOT/op» не могу потому что внутри лежит конфиг и результаты работы приложения. Пока такая проблема возникает не часть — решаю руками :(
Других проблем с откатом пока не встречал. Подскажите?
Проблема разных конфигов для дев версии и продакшена решаю отсутсвием конфига в svn :) app.conf.example, а при установке переименовываю и правлю под конкретную среду. В случае если должны изменится сами конфиги можно руками сходить и подправить.
С откатами на старые версии действительно есть проблема в виде не удаленных файлов от новых ревизий. «rm -rf $DOC_ROOT/op» не могу потому что внутри лежит конфиг и результаты работы приложения. Пока такая проблема возникает не часть — решаю руками :(
Других проблем с откатом пока не встречал. Подскажите?
>решаю отсутсвием конфига в svn
Я решаю намного проще, разделением конфигов с помощью SetEnv ;) В зависимости от окружения подгружается нужный конфиг, причем свой для всех разработчиков. Но sed тоже выход иногда.
>должны изменится сами конфиги можно руками сходить и подправить
Ага, и не забыть еще и в svn закинуть то что изменилось.
>«rm -rf $DOC_ROOT/op» не могу потому что внутри лежит конфиг и результаты работы
Угу, тож недостаток нехранения конфига в svnю В моем случае решается все это элементарно, даже без всяких SetEnv. Просто перед паковкой архива, надо переименовать конфиг из app.conf.example.production в app.conf
Я решаю намного проще, разделением конфигов с помощью SetEnv ;) В зависимости от окружения подгружается нужный конфиг, причем свой для всех разработчиков. Но sed тоже выход иногда.
>должны изменится сами конфиги можно руками сходить и подправить
Ага, и не забыть еще и в svn закинуть то что изменилось.
>«rm -rf $DOC_ROOT/op» не могу потому что внутри лежит конфиг и результаты работы
Угу, тож недостаток нехранения конфига в svnю В моем случае решается все это элементарно, даже без всяких SetEnv. Просто перед паковкой архива, надо переименовать конфиг из app.conf.example.production в app.conf
Что вам мешает ипользовать VCS для деплоймента?
По сути он и используется, только намного гибче. Конкретно в моем случае, админы вообще отказываются ставить на сервера svn, и я их понимаю.
Могу привести несколько причина почему это делать не стоит:
1. секурность, выставлять репозитории наружу далеко не все позволят.
2. выкладываться должны релизы, а не транк версия
3. следует из 2. часто то что видет у себя разработчик и то как это деплоится на сервер не всегда совпадает. К примеру конфиги настройки, куски дебаг кода, ресурсы, далеко не всегда должны уходить в продакшен. Все это должно быть исключено из релиза на стадии сборки
Первый пункт часто можно обойти, но осташиеся 2 делают деплоймент напрямую из репозитория кода просто бессмысленным
1. секурность, выставлять репозитории наружу далеко не все позволят.
2. выкладываться должны релизы, а не транк версия
3. следует из 2. часто то что видет у себя разработчик и то как это деплоится на сервер не всегда совпадает. К примеру конфиги настройки, куски дебаг кода, ресурсы, далеко не всегда должны уходить в продакшен. Все это должно быть исключено из релиза на стадии сборки
Первый пункт часто можно обойти, но осташиеся 2 делают деплоймент напрямую из репозитория кода просто бессмысленным
1. Решается конфигурацией http-сервера.
2. Можно выложить не только trunk, но и релизный branch.
3. Если есть такая необходимость, то можно запустить скрипт после обновления из ветки релиза. После теста, полученный код подставляется одной атомарной операцией вместо прежнего.
В чём минус релиза при помощи VCS?
2. Можно выложить не только trunk, но и релизный branch.
3. Если есть такая необходимость, то можно запустить скрипт после обновления из ветки релиза. После теста, полученный код подставляется одной атомарной операцией вместо прежнего.
В чём минус релиза при помощи VCS?
например то что обновление из svn не будет мгновенным, то есть ресурс может некоторое время не работать. Например в предложенном вами случае, вы собираетесь запустить скрипт после завершения выгрузки. То есть, если вам надо подменить конфиг, с другими параметрами соединения с БД, все время выгрузки, проект работать не будет (там будут неправельные параметры).
А теперь выгрузка с помощью скрипта. Вы ДО выгрузке вносите в код нужные изменения, удаляете все лишнее на девелоперской машине (что уже намного безопаснее, не так фатально rm -rf /), потом выгружаете на сервер, и делаете ln -s на новую версию кода. Новая версия появляется практически мгновенно. Так же мгновенно можно вернуть старую.
А теперь выгрузка с помощью скрипта. Вы ДО выгрузке вносите в код нужные изменения, удаляете все лишнее на девелоперской машине (что уже намного безопаснее, не так фатально rm -rf /), потом выгружаете на сервер, и делаете ln -s на новую версию кода. Новая версия появляется практически мгновенно. Так же мгновенно можно вернуть старую.
«После теста, полученный [новый] код подставляется одной атомарной операцией вместо прежнего.»
ну а тогда в чем разница то? У вас скрипт работает на сервере, у меня тот же самый скрипт работает на девелоперской машине. Очевидно что мой вариант безопаснее и проще в использовании. В вашем надо заходить на девсервер. В моем не надо. И не забываем что на продакшен-сервере у программиста может не быть нужных прав.
девсервер продакшн-сервер
Как раз в вашем случае нужен SSH доступ к продакшену, а в моём — не нужен.
К вашему скрипту претензий — никаких. Ну кроме, разве что, отсутствия кроссплатформенности.
К вашему скрипту претензий — никаких. Ну кроме, разве что, отсутствия кроссплатформенности.
Гы, а как вы на сервер попадете? :)))))
кросплатворменность есть. На всех системах, нужных програмисту он работает.
Вот вы неугомонны. 1. Windows — вполне годная платформа для программиста. 2. На сервер направится коммит в бранч релиза, который подхватывается post-commit-hook и запускает svn up и пр.
Тем что это экспорт это не релиз.
VCS это системы для управления исходным кодом. Процесс доставки приложения это нечто больше чем перезапись фаилов.
Реальный пример из моей практики. Приложение на питоне с мордой на extjs. Экст жс это примерно 200 классов разбитых по разным файлам. Которые надо склеить и минифицировать если выкладывать на продакшене. Конфигурация и урлы серверсайда имеют вариант развертки как со встроенным веб сервером для всего так и с использованием mod_wsgi для динамики и обычного apache для отдачи статики. Плюс к этому юнит тесты как для интерфейса так и для сервера. Структура папок организована стандартно мейвенских архетипов.
Все это прекрасно лежит на сервере. При достижении стабильного релиза выделяется в отдельные бранчи (вместе с тестом и прочим).
Какой коммандой svn/git/hg я могу выполнить деплоймент такой системы?
VCS это системы для управления исходным кодом. Процесс доставки приложения это нечто больше чем перезапись фаилов.
Реальный пример из моей практики. Приложение на питоне с мордой на extjs. Экст жс это примерно 200 классов разбитых по разным файлам. Которые надо склеить и минифицировать если выкладывать на продакшене. Конфигурация и урлы серверсайда имеют вариант развертки как со встроенным веб сервером для всего так и с использованием mod_wsgi для динамики и обычного apache для отдачи статики. Плюс к этому юнит тесты как для интерфейса так и для сервера. Структура папок организована стандартно мейвенских архетипов.
Все это прекрасно лежит на сервере. При достижении стабильного релиза выделяется в отдельные бранчи (вместе с тестом и прочим).
Какой коммандой svn/git/hg я могу выполнить деплоймент такой системы?
Естественно, задачи бывают разные. Задачу топикстартера VCS с простым хуком on-commit решает с головой.
Задачи имеют свойство усложняться ;)
Я не знаю задач топикстартера он их не описал. Но деплой продакшена по он-коммиту это мягко говоря опрометчивое решение — даже если считать что код не требует сборок и автоконфигрируется согласно окружению, нет никаких гарантий что бранч стабилен и что последний коммит не внес критическую ошибку.
Для этого есть релиз-менеджер, который этим и занимается. Т.е. это не проблема способа деплоя.
Вот, уже и релиз менеджера привели сюда)) Не находите ли что в итоге ваш вариант оказывается сложнее как в техническом так и организационном плане? Нужен релиз-менеджер, нужны какие-то отдельные ветки, нужно помнить в какую ветку и когда нужно комитить. В моем примере все просто, меняя параметры, можно выгружать куда угодно, а кто этим будет заниматься и когда, это уже дело десятое, хоть релиз-менеджер, хоть любой программист.
Во! Вы все ближе к правильно поставленомму техпроцессу.
Я при деплойменте делаю iso-образ, который потом монтирую вместо старого. В таком случае у меня на сервере всегда валяется несколько старых образов со старыми версиями, на которые я быстро могу переключить сервер, так удобнее немножко.
Для деплоя есть Capistrano. www.capify.org/index.php/Capistrano
Скрипты писать намного проще, и к тому же есть куча готовых рецептов на каждый случай. capitate.rubyforge.org/recipes/index.html
Скрипты писать намного проще, и к тому же есть куча готовых рецептов на каждый случай. capitate.rubyforge.org/recipes/index.html
вот ну написал же специально первый абзац… и все равно суют Capistranо…
Так если уже все готово, прекрасно работает и удобно, какой смысл делать свои костыли?
Вам надо было хоть как-то изучить эту тему и ознакомиться как это делается у людей.
Если бы скрипт соответствал тому что написано в первом абзаце, то ладно. А так оно порождает еще больше трудностей и возможных багов. Соответстует только тому, что он неуниверсальный, и для чуть дургой задачи продолжая идти этим же путем нужно будет затратить еще столько же времени.
Вобщем каждому свое.
Вам надо было хоть как-то изучить эту тему и ознакомиться как это делается у людей.
Если бы скрипт соответствал тому что написано в первом абзаце, то ладно. А так оно порождает еще больше трудностей и возможных багов. Соответстует только тому, что он неуниверсальный, и для чуть дургой задачи продолжая идти этим же путем нужно будет затратить еще столько же времени.
Вобщем каждому свое.
Насчет Capistrano я знаю, и даже дал ссылку на статью, где в том числе рассматривается и он. А в чем смысл? Да в том что мой вариант работает практически на любой машине, и любом сервере. Не нужно дополнительно устанавливать Capistrano, не нужен рубиновый gem и сам ruby, не нужно знать ruby (shell язык должен знать каждый), при этом скрипт получается проще (хочу заметить что там куча кода для красоты, без которго можно обойтись).
НО, безусловно, Capistrano тоже имеет право на жизнь.
НО, безусловно, Capistrano тоже имеет право на жизнь.
UFO just landed and posted this here
прошу перечитать первый обзац. и не просто перечитать, но еще и подумать над ним.
не понимаю каким боком тут svn:externals… Собственно он итак external если чо, но я не понимаю что это меняет.
не понимаю каким боком тут svn:externals… Собственно он итак external если чо, но я не понимаю что это меняет.
UFO just landed and posted this here
то есть он не может быть вот тут https://your.svnserver.ru/svn/repos/yourptoject/envos например, да?
UFO just landed and posted this here
Нет его там нет
UFO just landed and posted this here
*бьюсь головой об стену*
Тупим?© Повторяю, envos итак external. Дальше что то объяснять я бессилен… Я так понял вы либо не прочли статью либо просто ничего не поняли. Думайте, потому что как еще нужно разжевать я не знаю.
Тупим?© Повторяю, envos итак external. Дальше что то объяснять я бессилен… Я так понял вы либо не прочли статью либо просто ничего не поняли. Думайте, потому что как еще нужно разжевать я не знаю.
UFO just landed and posted this here
Никто и не хамит. Я просто уже сказал что envos ледит в другой svn-директории. Это сделано для того что бы один код можно было использовать во многих проектах:
./project1
./project2
./projectN
./envos
При этом envos external потому что он разрабатывается отдельно, и лежит в другом репозитории. Потому у меня есть возможность паковать только код приложения, без envosа, ибо не всегда нужно выгружать новую версию движка. И вот это то как раз и уменьшает общий вес «пакета».
./project1
./project2
./projectN
./envos
При этом envos external потому что он разрабатывается отдельно, и лежит в другом репозитории. Потому у меня есть возможность паковать только код приложения, без envosа, ибо не всегда нужно выгружать новую версию движка. И вот это то как раз и уменьшает общий вес «пакета».
UFO just landed and posted this here
Мы в своё время для этих целей Buildbot использовали
как то некроссплатформенно
rsync работает гораздо эффективнее, чем tar в данном случае. А еще есть интересное решение — использовать sshfs
Вас правильно испугало множество зависимостей у Capistrano.
Но есть одно НО — Capistrano надо поставить только на один хост, откуда происходит выкатка.
Сам деплой Capistrano выполняет с деплой-машины посредством SSH и так далее, то есть без необходимости устанавливать его на целевые машины.
Удовольствие: ведение историй выкатки, откат, множество целей, множество задач, простой и ясный язык, расширяемость.
Но есть одно НО — Capistrano надо поставить только на один хост, откуда происходит выкатка.
Сам деплой Capistrano выполняет с деплой-машины посредством SSH и так далее, то есть без необходимости устанавливать его на целевые машины.
Удовольствие: ведение историй выкатки, откат, множество целей, множество задач, простой и ясный язык, расширяемость.
Sign up to leave a comment.
Простой скрипт деплоя