@RVK27 ноя 2009 в 08:36

Простой скрипт деплоя

5 мин

9.1K

Веб-разработка *

-1

Комментарии 62

@lacki 27 ноя 2009 в 09:27

Экономить трафик на сжатии в архив нет необходимости — обхожусь одной командой
ssh exaple_host.com «svn --force --username=export_user --password=export_password export https://example.com/svn/project/ /project/dist»

@RVK 27 ноя 2009 в 09:37

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

@lacki 27 ноя 2009 в 09:48

С наличием svn на сервере проблем нет.
Проблема разных конфигов для дев версии и продакшена решаю отсутсвием конфига в svn :) app.conf.example, а при установке переименовываю и правлю под конкретную среду. В случае если должны изменится сами конфиги можно руками сходить и подправить.

С откатами на старые версии действительно есть проблема в виде не удаленных файлов от новых ревизий. «rm -rf $DOC_ROOT/op» не могу потому что внутри лежит конфиг и результаты работы приложения. Пока такая проблема возникает не часть — решаю руками :(
Других проблем с откатом пока не встречал. Подскажите?

@RVK 27 ноя 2009 в 09:54

>решаю отсутсвием конфига в svn

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

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

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

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

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

@andrew_tch 27 ноя 2009 в 09:37

Что вам мешает ипользовать VCS для деплоймента?

@RVK 27 ноя 2009 в 09:39

По сути он и используется, только намного гибче. Конкретно в моем случае, админы вообще отказываются ставить на сервера svn, и я их понимаю.

@andrew_tch 27 ноя 2009 в 09:42

Прально, надо git ставить.

@RVK 27 ноя 2009 в 09:47

На продакшен сервере вообще никакая VCS не нужна.

@andrew_tch 27 ноя 2009 в 09:52

Ей деплоить в сотни раз легче. Скажите это опере у которой на сайте недавно нашли остатки svn.

@RVK 27 ноя 2009 в 09:59

повторяю, никакая VCS на продакшен сервере не нужна. А то что у оперв там нашли, это вообще не в тему. Я так понимаю там .svn нашли директории. Как это относится к моему примеру, и вообще к наличию SVN на сервере я не понимаю.

@kivsiak 27 ноя 2009 в 09:52

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

Первый пункт часто можно обойти, но осташиеся 2 делают деплоймент напрямую из репозитория кода просто бессмысленным

@Vanav 27 ноя 2009 в 13:16

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

В чём минус релиза при помощи VCS?

@RVK 27 ноя 2009 в 13:22

например то что обновление из svn не будет мгновенным, то есть ресурс может некоторое время не работать. Например в предложенном вами случае, вы собираетесь запустить скрипт ~~после завершения~~ выгрузки. То есть, если вам надо подменить конфиг, с другими параметрами соединения с БД, все время выгрузки, проект работать не будет (там будут неправельные параметры).
А теперь выгрузка с помощью скрипта. Вы ДО выгрузке вносите в код нужные изменения, удаляете все лишнее на девелоперской машине (что уже намного безопаснее, не так фатально rm -rf /), потом выгружаете на сервер, и делаете ln -s на новую версию кода. Новая версия появляется практически мгновенно. Так же мгновенно можно вернуть старую.

@Vanav 27 ноя 2009 в 13:24

«После теста, полученный [новый] код подставляется одной атомарной операцией вместо прежнего.»

@RVK 27 ноя 2009 в 14:01

ну а тогда в чем разница то? У вас скрипт работает на сервере, у меня тот же самый скрипт работает на девелоперской машине. Очевидно что мой вариант безопаснее и проще в использовании. В вашем надо заходить на девсервер. В моем не надо. И не забываем что на продакшен-сервере у программиста может не быть нужных прав.

@RVK 27 ноя 2009 в 14:01

девсервер продакшн-сервер

@Vanav 27 ноя 2009 в 14:22

Как раз в вашем случае нужен SSH доступ к продакшену, а в моём — не нужен.
К вашему скрипту претензий — никаких. Ну кроме, разве что, отсутствия кроссплатформенности.

@RVK 27 ноя 2009 в 14:25

Гы, а как вы на сервер попадете? :)))))

@RVK 27 ноя 2009 в 14:25

кросплатворменность есть. На всех системах, нужных програмисту он работает.

@Vanav 27 ноя 2009 в 14:33

Вот вы неугомонны. 1. Windows — вполне годная платформа для программиста. 2. На сервер направится коммит в бранч релиза, который подхватывается post-commit-hook и запускает svn up и пр.

@RVK 27 ноя 2009 в 14:41

1. а денвер замечательный пакет для установки php :)
2. А если не надо выгружать этот релиз? А если сначала надо выгрузить на тестовый сервер?

@Vanav 27 ноя 2009 в 14:42

1. Чем плох Денвер у девелопера?
2. Коммит в тестовый бранч.

@RVK 27 ноя 2009 в 14:45

1. не чем. пользуйтесь на здоровье. :))))
2. а зачем? вы уже тут такой огород нагородили. Для чего? Что бы доказать что есть другие решения. Я сам знаю, спасибо.

@Vanav 27 ноя 2009 в 14:48

Да я и не с вами общался (см. выше).

@kivsiak 27 ноя 2009 в 19:43

Тем что это экспорт это не релиз.

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

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

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

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

@Vanav 27 ноя 2009 в 20:24

Естественно, задачи бывают разные. Задачу топикстартера VCS с простым хуком on-commit решает с головой.

@RVK 27 ноя 2009 в 20:35

Задачи имеют свойство усложняться ;)

@kivsiak 27 ноя 2009 в 21:12

Я не знаю задач топикстартера он их не описал. Но деплой продакшена по он-коммиту это мягко говоря опрометчивое решение — даже если считать что код не требует сборок и автоконфигрируется согласно окружению, нет никаких гарантий что бранч стабилен и что последний коммит не внес критическую ошибку.

@Vanav 28 ноя 2009 в 09:46

Для этого есть релиз-менеджер, который этим и занимается. Т.е. это не проблема способа деплоя.

@RVK 28 ноя 2009 в 12:27

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

@Alexander_N 29 ноя 2009 в 16:43

Такое чувство, что благодаря Вам мы теперь можем пользоваться супер-пупер скриптом для деплоя с огромным магическим потенциалом. Ну прямо всё сам делает и все задачи решает. Искренне рад за Вас!

@RVK 29 ноя 2009 в 22:46

Да нет, опять же напомню про первый абзац. Но ваш вариант хуже, хотя и не отрицаю что в некоторых ситуациях он может быть и приемлем. Вообще, делать билд на сервере не очень хорошая идея. Потому я и отказался от Capistrano.

@kivsiak 28 ноя 2009 в 15:31

Во! Вы все ближе к правильно поставленомму техпроцессу.

@silentroach 27 ноя 2009 в 09:49

Я при деплойменте делаю iso-образ, который потом монтирую вместо старого. В таком случае у меня на сервере всегда валяется несколько старых образов со старыми версиями, на которые я быстро могу переключить сервер, так удобнее немножко.

@kastigar 27 ноя 2009 в 09:57

Интересно узнать, почему именно iso? Какие-то преимущества перед другими?

@silentroach 27 ноя 2009 в 09:59

Не знаю даже, просто первым в голову пришло. А какие лучше?

@kastigar 27 ноя 2009 в 10:07

Та я то не знаю, думал Вы какие оценки проводили )

@silentroach 27 ноя 2009 в 10:09

Не, ничего не производил, взял самое распространенное :)

@Sannis 28 ноя 2009 в 12:53

Тогда можно было просто несколько папок держать, зачем монтировать образ? Разве что для ускорения из-за разворачивания в память, если возможности позволяют.

@silentroach 28 ноя 2009 в 13:05

Ну основной плюс — readonly. Так, на всякий случай.

@Alexander_N 27 ноя 2009 в 11:19

Для деплоя есть Capistrano. www.capify.org/index.php/Capistrano
Скрипты писать намного проще, и к тому же есть куча готовых рецептов на каждый случай. capitate.rubyforge.org/recipes/index.html

@RVK 27 ноя 2009 в 12:21

вот ну написал же специально первый абзац… и все равно суют Capistranо…

@Alexander_N 27 ноя 2009 в 13:11

Так если уже все готово, прекрасно работает и удобно, какой смысл делать свои костыли?
Вам надо было хоть как-то изучить эту тему и ознакомиться как это делается у людей.

Если бы скрипт соответствал тому что написано в первом абзаце, то ладно. А так оно порождает еще больше трудностей и возможных багов. Соответстует только тому, что он неуниверсальный, и для чуть дургой задачи продолжая идти этим же путем нужно будет затратить еще столько же времени.
Вобщем каждому свое.

@RVK 27 ноя 2009 в 13:35

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

НО, безусловно, Capistrano тоже имеет право на жизнь.