Comments 62
Экономить трафик на сжатии в архив нет необходимости — обхожусь одной командой
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

Я решаю намного проще, разделением конфигов с помощью SetEnv ;) В зависимости от окружения подгружается нужный конфиг, причем свой для всех разработчиков. Но sed тоже выход иногда.

>должны изменится сами конфиги можно руками сходить и подправить

Ага, и не забыть еще и в svn закинуть то что изменилось.

>«rm -rf $DOC_ROOT/op» не могу потому что внутри лежит конфиг и результаты работы

Угу, тож недостаток нехранения конфига в svnю В моем случае решается все это элементарно, даже без всяких SetEnv. Просто перед паковкой архива, надо переименовать конфиг из app.conf.example.production в app.conf

По сути он и используется, только намного гибче. Конкретно в моем случае, админы вообще отказываются ставить на сервера svn, и я их понимаю.
Ей деплоить в сотни раз легче. Скажите это опере у которой на сайте недавно нашли остатки svn.
повторяю, никакая VCS на продакшен сервере не нужна. А то что у оперв там нашли, это вообще не в тему. Я так понимаю там .svn нашли директории. Как это относится к моему примеру, и вообще к наличию SVN на сервере я не понимаю.
Могу привести несколько причина почему это делать не стоит:
1. секурность, выставлять репозитории наружу далеко не все позволят.
2. выкладываться должны релизы, а не транк версия
3. следует из 2. часто то что видет у себя разработчик и то как это деплоится на сервер не всегда совпадает. К примеру конфиги настройки, куски дебаг кода, ресурсы, далеко не всегда должны уходить в продакшен. Все это должно быть исключено из релиза на стадии сборки

Первый пункт часто можно обойти, но осташиеся 2 делают деплоймент напрямую из репозитория кода просто бессмысленным
1. Решается конфигурацией http-сервера.
2. Можно выложить не только trunk, но и релизный branch.
3. Если есть такая необходимость, то можно запустить скрипт после обновления из ветки релиза. После теста, полученный код подставляется одной атомарной операцией вместо прежнего.

В чём минус релиза при помощи VCS?
например то что обновление из svn не будет мгновенным, то есть ресурс может некоторое время не работать. Например в предложенном вами случае, вы собираетесь запустить скрипт после завершения выгрузки. То есть, если вам надо подменить конфиг, с другими параметрами соединения с БД, все время выгрузки, проект работать не будет (там будут неправельные параметры).
А теперь выгрузка с помощью скрипта. Вы ДО выгрузке вносите в код нужные изменения, удаляете все лишнее на девелоперской машине (что уже намного безопаснее, не так фатально rm -rf /), потом выгружаете на сервер, и делаете ln -s на новую версию кода. Новая версия появляется практически мгновенно. Так же мгновенно можно вернуть старую.
«После теста, полученный [новый] код подставляется одной атомарной операцией вместо прежнего.»
ну а тогда в чем разница то? У вас скрипт работает на сервере, у меня тот же самый скрипт работает на девелоперской машине. Очевидно что мой вариант безопаснее и проще в использовании. В вашем надо заходить на девсервер. В моем не надо. И не забываем что на продакшен-сервере у программиста может не быть нужных прав.
Как раз в вашем случае нужен SSH доступ к продакшену, а в моём — не нужен.
К вашему скрипту претензий — никаких. Ну кроме, разве что, отсутствия кроссплатформенности.
кросплатворменность есть. На всех системах, нужных програмисту он работает.
Вот вы неугомонны. 1. Windows — вполне годная платформа для программиста. 2. На сервер направится коммит в бранч релиза, который подхватывается post-commit-hook и запускает svn up и пр.
1. а денвер замечательный пакет для установки php :)
2. А если не надо выгружать этот релиз? А если сначала надо выгрузить на тестовый сервер?
1. Чем плох Денвер у девелопера?
2. Коммит в тестовый бранч.
1. не чем. пользуйтесь на здоровье. :))))
2. а зачем? вы уже тут такой огород нагородили. Для чего? Что бы доказать что есть другие решения. Я сам знаю, спасибо.
Тем что это экспорт это не релиз.

VCS это системы для управления исходным кодом. Процесс доставки приложения это нечто больше чем перезапись фаилов.

Реальный пример из моей практики. Приложение на питоне с мордой на extjs. Экст жс это примерно 200 классов разбитых по разным файлам. Которые надо склеить и минифицировать если выкладывать на продакшене. Конфигурация и урлы серверсайда имеют вариант развертки как со встроенным веб сервером для всего так и с использованием mod_wsgi для динамики и обычного apache для отдачи статики. Плюс к этому юнит тесты как для интерфейса так и для сервера. Структура папок организована стандартно мейвенских архетипов.

Все это прекрасно лежит на сервере. При достижении стабильного релиза выделяется в отдельные бранчи (вместе с тестом и прочим).

Какой коммандой svn/git/hg я могу выполнить деплоймент такой системы?

Естественно, задачи бывают разные. Задачу топикстартера VCS с простым хуком on-commit решает с головой.
Я не знаю задач топикстартера он их не описал. Но деплой продакшена по он-коммиту это мягко говоря опрометчивое решение — даже если считать что код не требует сборок и автоконфигрируется согласно окружению, нет никаких гарантий что бранч стабилен и что последний коммит не внес критическую ошибку.
Для этого есть релиз-менеджер, который этим и занимается. Т.е. это не проблема способа деплоя.
Вот, уже и релиз менеджера привели сюда)) Не находите ли что в итоге ваш вариант оказывается сложнее как в техническом так и организационном плане? Нужен релиз-менеджер, нужны какие-то отдельные ветки, нужно помнить в какую ветку и когда нужно комитить. В моем примере все просто, меняя параметры, можно выгружать куда угодно, а кто этим будет заниматься и когда, это уже дело десятое, хоть релиз-менеджер, хоть любой программист.
Такое чувство, что благодаря Вам мы теперь можем пользоваться супер-пупер скриптом для деплоя с огромным магическим потенциалом. Ну прямо всё сам делает и все задачи решает. Искренне рад за Вас!
Да нет, опять же напомню про первый абзац. Но ваш вариант хуже, хотя и не отрицаю что в некоторых ситуациях он может быть и приемлем. Вообще, делать билд на сервере не очень хорошая идея. Потому я и отказался от Capistrano.
Я при деплойменте делаю iso-образ, который потом монтирую вместо старого. В таком случае у меня на сервере всегда валяется несколько старых образов со старыми версиями, на которые я быстро могу переключить сервер, так удобнее немножко.
Интересно узнать, почему именно iso? Какие-то преимущества перед другими?
Тогда можно было просто несколько папок держать, зачем монтировать образ? Разве что для ускорения из-за разворачивания в память, если возможности позволяют.
вот ну написал же специально первый абзац… и все равно суют Capistranо…
Так если уже все готово, прекрасно работает и удобно, какой смысл делать свои костыли?
Вам надо было хоть как-то изучить эту тему и ознакомиться как это делается у людей.

Если бы скрипт соответствал тому что написано в первом абзаце, то ладно. А так оно порождает еще больше трудностей и возможных багов. Соответстует только тому, что он неуниверсальный, и для чуть дургой задачи продолжая идти этим же путем нужно будет затратить еще столько же времени.
Вобщем каждому свое.
Насчет Capistrano я знаю, и даже дал ссылку на статью, где в том числе рассматривается и он. А в чем смысл? Да в том что мой вариант работает практически на любой машине, и любом сервере. Не нужно дополнительно устанавливать Capistrano, не нужен рубиновый gem и сам ruby, не нужно знать ruby (shell язык должен знать каждый), при этом скрипт получается проще (хочу заметить что там куча кода для красоты, без которго можно обойтись).

НО, безусловно, Capistrano тоже имеет право на жизнь.
Чем оно лучше rsync?
Чем оно лучше Capistrano?
Зачем паковать фреймворк отдельно, если есть svn:externals?
прошу перечитать первый обзац. и не просто перечитать, но еще и подумать над ним.

не понимаю каким боком тут svn:externals… Собственно он итак external если чо, но я не понимаю что это меняет.
то есть он не может быть вот тут https://your.svnserver.ru/svn/repos/yourptoject/envos например, да?
нет, я не об этом. Он уже есть (по вашим словам) в yourproject.tar.gz, поэтому заливать его во второй раз не нужно?
А надо бы. Причём надо бы добавить посредством svn:externals. Тогда фреймворк экспортился бы и, соответственно, паковался бы вместе с исходниками. Что в итоге уменьшает общий вес «пакета».
*бьюсь головой об стену*

Тупим?© Повторяю, envos итак external. Дальше что то объяснять я бессилен… Я так понял вы либо не прочли статью либо просто ничего не поняли. Думайте, потому что как еще нужно разжевать я не знаю.
Тупим?©
Не хамите, молодой человек. Тупость — это не осилить man rsync (и, по всей видимости, man ssh за компанию).
Повторяю, envos итак external.
Похоже, мы разговариваем на разных языках. Не вижу смысла продолжать.
Никто и не хамит. Я просто уже сказал что envos ледит в другой svn-директории. Это сделано для того что бы один код можно было использовать во многих проектах:

./project1
./project2
./projectN
./envos

При этом envos external потому что он разрабатывается отдельно, и лежит в другом репозитории. Потому у меня есть возможность паковать только код приложения, без envosа, ибо не всегда нужно выгружать новую версию движка. И вот это то как раз и уменьшает общий вес «пакета».
почему это? Работает везде и в Ubuntu и Gentoo и FreeBSD :) Очень кросплатформено. Или вам надо что бы скрипт еще и в Windows работал? А смысл?
я sshfs использую для монитрования кода из песочницы. В прниципе обе иде имеют право на жизнь
Вас правильно испугало множество зависимостей у Capistrano.

Но есть одно НО — Capistrano надо поставить только на один хост, откуда происходит выкатка.

Сам деплой Capistrano выполняет с деплой-машины посредством SSH и так далее, то есть без необходимости устанавливать его на целевые машины.

Удовольствие: ведение историй выкатки, откат, множество целей, множество задач, простой и ясный язык, расширяемость.
Only those users with full accounts are able to leave comments. Log in, please.