Насчет Capistrano я знаю, и даже дал ссылку на статью, где в том числе рассматривается и он. А в чем смысл? Да в том что мой вариант работает практически на любой машине, и любом сервере. Не нужно дополнительно устанавливать Capistrano, не нужен рубиновый gem и сам ruby, не нужно знать ruby (shell язык должен знать каждый), при этом скрипт получается проще (хочу заметить что там куча кода для красоты, без которго можно обойтись).
НО, безусловно, Capistrano тоже имеет право на жизнь.
например то что обновление из svn не будет мгновенным, то есть ресурс может некоторое время не работать. Например в предложенном вами случае, вы собираетесь запустить скрипт после завершения выгрузки. То есть, если вам надо подменить конфиг, с другими параметрами соединения с БД, все время выгрузки, проект работать не будет (там будут неправельные параметры).
А теперь выгрузка с помощью скрипта. Вы ДО выгрузке вносите в код нужные изменения, удаляете все лишнее на девелоперской машине (что уже намного безопаснее, не так фатально rm -rf /), потом выгружаете на сервер, и делаете ln -s на новую версию кода. Новая версия появляется практически мгновенно. Так же мгновенно можно вернуть старую.
повторяю, никакая VCS на продакшен сервере не нужна. А то что у оперв там нашли, это вообще не в тему. Я так понимаю там .svn нашли директории. Как это относится к моему примеру, и вообще к наличию SVN на сервере я не понимаю.
Я решаю намного проще, разделением конфигов с помощью SetEnv ;) В зависимости от окружения подгружается нужный конфиг, причем свой для всех разработчиков. Но sed тоже выход иногда.
>должны изменится сами конфиги можно руками сходить и подправить
Ага, и не забыть еще и в svn закинуть то что изменилось.
>«rm -rf $DOC_ROOT/op» не могу потому что внутри лежит конфиг и результаты работы
Угу, тож недостаток нехранения конфига в svnю В моем случае решается все это элементарно, даже без всяких SetEnv. Просто перед паковкой архива, надо переименовать конфиг из app.conf.example.production в app.conf
это только в том случае если на сервере есть svn
Так же часто бывает необходимо, перед выгрузкой, произвести над кодом некоторые манипуляции, например удалить тесты (которые на продакшене не нужны), изменить парметры конфигов.
Еще одно приемущество подобного подхода, это простота реализации отката до предыдущей версии, в случае непредвиденной ошибки.
1. Я специально в примере указал что это всего лишь пример. И даже дальше, по ходу в комментариях я указал что целесообразнее разделить кешхеадер по первому ключу.
2. Я в курсе что там хранилось еще и время жизни, и даже написал что хранить там можно все что угодно. Повторяюсь, пример упрощенный.
3. Можно подробнее узнать, а чья же это, позвольте, идея? Ну как минимум моя и Антона, ибо эту реализацию мы обсуждали с ним вдвоем. Сама же реализация в коде была выполнена мной от и до.
спасибо, удивительно, но после тщательной уборки внутри системника, мышка работает нормально. вспоминается анекдот «а ты по колесу стучал? а капотом хлопал?.....»
вспомнил что у меня паралельно еще винда стоит. там та же проблема. причем заметил что если нажимаешь несильно на кнопку, то все нормально. но нажмешь чуть сильнее, и с вероятностью 8 из 10 получается двойной, тройной или даже четверной клик. так что дело похоже в железе. поэтому я откопал старую PS/2 мышку и подключил. с ней все хорошо, глюков нет.
с другими устройствами никаких проблем. самы мышку воткнул в другой разьем, те же проблемы. за совет спасибо, попробую лайвсиди предыдущей версии убунты.
НО, безусловно, Capistrano тоже имеет право на жизнь.
после завершениявыгрузки. То есть, если вам надо подменить конфиг, с другими параметрами соединения с БД, все время выгрузки, проект работать не будет (там будут неправельные параметры).А теперь выгрузка с помощью скрипта. Вы ДО выгрузке вносите в код нужные изменения, удаляете все лишнее на девелоперской машине (что уже намного безопаснее, не так фатально rm -rf /), потом выгружаете на сервер, и делаете ln -s на новую версию кода. Новая версия появляется практически мгновенно. Так же мгновенно можно вернуть старую.
не понимаю каким боком тут svn:externals… Собственно он итак external если чо, но я не понимаю что это меняет.
Я решаю намного проще, разделением конфигов с помощью SetEnv ;) В зависимости от окружения подгружается нужный конфиг, причем свой для всех разработчиков. Но sed тоже выход иногда.
>должны изменится сами конфиги можно руками сходить и подправить
Ага, и не забыть еще и в svn закинуть то что изменилось.
>«rm -rf $DOC_ROOT/op» не могу потому что внутри лежит конфиг и результаты работы
Угу, тож недостаток нехранения конфига в svnю В моем случае решается все это элементарно, даже без всяких SetEnv. Просто перед паковкой архива, надо переименовать конфиг из app.conf.example.production в app.conf
Так же часто бывает необходимо, перед выгрузкой, произвести над кодом некоторые манипуляции, например удалить тесты (которые на продакшене не нужны), изменить парметры конфигов.
Еще одно приемущество подобного подхода, это простота реализации отката до предыдущей версии, в случае непредвиденной ошибки.
2. Я в курсе что там хранилось еще и время жизни, и даже написал что хранить там можно все что угодно. Повторяюсь, пример упрощенный.
3. Можно подробнее узнать, а чья же это, позвольте, идея? Ну как минимум моя и Антона, ибо эту реализацию мы обсуждали с ним вдвоем. Сама же реализация в коде была выполнена мной от и до.