расскажите, как деплоить без релизов

[Alex Scherbanov]

Расскажите, как вы деплоите и апдейтите в продакшн без релизов.

Пытаюсь разобратья в обеих схемах, понять плюсы и минусы.

Хочу сделать одну штуку на cowboy+sockjs. Получится ли апдейтить так, чтобы ни одного разрыва?

[Max Lapshin]

Это уже неоднократно обсуждалось.

Первая мысль: почему вы решили, что используя релизы вы действительно
будете деплоить без разрывов? Пока что никто из ярых защитников этого
подхода не смог внятно объяснить, чего он собирается делать со всеми
стейтами системы.

Вторая мысль: если вы боитесь разрывов, что что с вами случится, когда
блок питания выжжет ваш единственный сервер?

Третья мысль: о каком «без разрывов» вы говорите, обсуждая вебсокеты в
интернете? Для вас проблема реконнектить пользователей? Срочно
переписывайте клиента!

[Alex Scherbanov]

On Tuesday, August 13, 2013 5:11:14 PM UTC+4, Max Lapshin wrote:

Первая мысль: почему вы решили, что используя релизы вы действительно 
будете деплоить без разрывов?

Да вопрос был про обе схемы. Я еще не начал писать, хочу найти направление, в котором копать. Читал твои (ничего, если я на ты, ок?) посты про проблемы с релизами, прекрасно понимаю, что there is no silver bullet.

Расскажи, пожалуйста, как ты деплоишь и апдейтишь без релизов, я хочу попробовать и выбрать сбособ, который мне будет удобней.

[Alex Scherbanov]

Интересно, как собирать: достаточно ли ребара или надо вручную; что и как паковать и переносить на сервер; как запускать, использовать ли tmux или screen; как апдейтить код в продакшене. Совсем роскошно будет, если расскажешь еще примерно, как клиента готовить, чтобы в этой связке cowboy+sockjs по возможности при апдейтах или перезапусках информация не терялась.

[Mikhail Gusarov]

screen?!

Best regards,
Mikhail Gusarov.


2013/8/13 Alex Scherbanov <al...@egotv.ru>:

> --
> --
> Страница рассылки: http://groups.google.com/group/erlang-russian
> Новости: http://erlanger.ru
> Чат: xmpp://erl...@conference.jabber.ru
> Чат для оффтопа: xmpp://erlang...@conference.jabber.ru
> Правила, действующие в чате и рассылке:
> http://erlanger.ru/ru/erlang-at-conference-jabber-ru
>
> Написать письмо: erlang-...@googlegroups.com
> Отписаться: erlang-russia...@googlegroups.com
> ---
> Вы получили это сообщение, поскольку подписаны на группу Erlang по-русски.
>
> Чтобы отказаться от подписки на эту группу и перестать получать из нее
> сообщения, отправьте электронное письмо на адрес
> erlang-russia...@googlegroups.com.
> Настройки подписки и доставки писем:
> https://groups.google.com/groups/opt_out.
>
>

[Alex Scherbanov]

On Tuesday, August 13, 2013 5:41:42 PM UTC+4, Mikhail Gusarov wrote:

screen?!

Ну там, например, запустить ноду и отдетачить сессию. Вот фиг знает, потому и спрашиваю. 

[Evgen Polivoda]

Я пользуюсь  run_erl (можете погуглить).

В кратце если:

1. запускаю ерланг так run_erl -daemon /var/log/erlang/ /var/log/erlang/ erl

он автоматом детачится от консоли и работает в демон-режиме

в /var/log/erlang/ он создает два пайпа на read и write

так же там создаются логи с выводом ерланговской консоли

2. управлять всей этой фигатенью достаточно просто.

echo команды в пайп write  - передает ее ерлангу, например:

echo "my_app:start()." >  /var/log/erlang/erlang.pipe.1.w  - просто запускает ваше приложение, что вы можете увидеть в логе

или так например: echo "1+1."  > /var/log/erlang/erlang.pipe.1.w 

то есть тоже что вы бы писали и в консоли ерланга только через echo.

в принципе немного геморно, но я наклепал на баше скриптов и просто их запускаю.

вторник, 13 августа 2013 г., 16:07:28 UTC+3 пользователь Alex Scherbanov написал:

[zheka_13]

Я пользуюсь  run_erl (можете погуглить).

В кратце если:

1. запускаю ерланг так run_erl -daemon /var/log/erlang/ /var/log/erlang/ erl

он автоматом детачится от консоли и работает в демон-режиме

в /var/log/erlang/ он создает два пайпа на read и write

так же там создаются логи с выводом ерланговской консоли

2. управлять всей этой фигатенью достаточно просто.

echo команды в пайп write  - передает ее ерлангу, например:

echo "my_app:start()." >  /var/log/erlang/erlang.pipe.1.w  - просто запускает ваше приложение, что вы можете увидеть в логе

или так например: echo "1+1."  > /var/log/erlang/erlang.pipe.1.w 

то есть тоже что вы бы писали и в консоли ерланга только через echo.

в принципе немного геморно, но я наклепал на баше скриптов и просто их запускаю.

13 августа 2013 г., 17:04 пользователь Alex Scherbanov <al...@egotv.ru> написал:

On Tuesday, August 13, 2013 5:41:42 PM UTC+4, Mikhail Gusarov wrote:

screen?!

Ну там, например, запустить ноду и отдетачить сессию. Вот фиг знает, потому и спрашиваю. 

--

[Yuri Zhloba]

"echo команды в пайп write  - передает ее ерлангу, например:

echo "my_app:start()." >  /var/log/erlang/erlang.pipe.1.w  - просто запускает ваше приложение, что вы 

можете увидеть в логе

или так например: echo "1+1."  > /var/log/erlang/erlang.pipe.1.w 

то есть тоже что вы бы писали и в консоли ерланга только через echo."

А зачем это все? Удобнее ведь просто подключиться эрланг-консолью?

13 августа 2013 г., 17:49 пользователь zheka_13 <pol...@gmail.com> написал:

--
Yuri Zhloba

skype: yzh44yzh
jabber: yzh4...@gmail.com
phone: +375 44 793 33 73

[Naim sh]

О©╫О©╫О©╫О©╫О©╫О©╫О©╫ , О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫ screen [ http://xgu.ru/wiki/screen ] О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ tmux
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ .


On 13/08/13 18:02, Yuri Zhloba wrote:

"echo О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫ write О©╫- О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫:

echo "my_app:start()." > О©╫/var/log/erlang/erlang.pipe.1.w О©╫- О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫ы 

О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫

О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫: echo "1+1." О©╫> /var/log/erlang/erlang.pipe.1.wО©╫

О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ echo."

О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫? О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫-О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫?

13 О©╫О©╫О©╫О©╫О©╫О©╫О©╫ 2013 О©╫., 17:49 О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ zheka_13 <pol...@gmail.com> О©╫О©╫О©╫О©╫О©╫О©╫О©╫:

О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫run_erl (О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫).

О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫:

1. О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫к run_erl -daemon /var/log/erlang/ /var/log/erlang/ erl

О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫-О©╫О©╫О©╫О©╫О©╫О©╫

в /var/log/erlang/ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ read О©╫ write

О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫

2. О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫.

echo О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫ write О©╫- О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫:

echo "my_app:start()." > О©╫/var/log/erlang/erlang.pipe.1.w О©╫- О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫

О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫: echo "1+1." О©╫> /var/log/erlang/erlang.pipe.1.wО©╫

О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ echo.

О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫.

13 О©╫О©╫О©╫О©╫О©╫О©╫О©╫ 2013 О©╫., 17:04 О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ Alex Scherbanov <al...@egotv.ru> О©╫О©╫О©╫О©╫О©╫О©╫О©╫:

On Tuesday, August 13, 2013 5:41:42 PM UTC+4, Mikhail Gusarov wrote:

screen?!

О©╫О©╫ О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫.О©╫

--
--
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫: http://groups.google.com/group/erlang-russian
О©╫О©╫О©╫О©╫О©╫О©╫О©╫: http://erlanger.ru
О©╫О©╫О©╫: xmpp://erl...@conference.jabber.ru
О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫: xmpp://erlang...@conference.jabber.ru
О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫: http://erlanger.ru/ru/erlang-at-conference-jabber-ru
О©╫
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫: erlang-...@googlegroups.com
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫: erlang-russia...@googlegroups.com
---
О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ Erlang О©╫О©╫-О©╫О©╫О©╫О©╫О©╫О©╫.
О©╫
О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ erlang-russia...@googlegroups.com.
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫: https://groups.google.com/groups/opt_out.
О©╫
О©╫

--
--
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫: http://groups.google.com/group/erlang-russian
О©╫О©╫О©╫О©╫О©╫О©╫О©╫: http://erlanger.ru
О©╫О©╫О©╫: xmpp://erl...@conference.jabber.ru
О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫: xmpp://erlang...@conference.jabber.ru
О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫: http://erlanger.ru/ru/erlang-at-conference-jabber-ru
О©╫
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫: erlang-...@googlegroups.com
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫: erlang-russia...@googlegroups.com
---
О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ Erlang О©╫О©╫-О©╫О©╫О©╫О©╫О©╫О©╫.
О©╫
О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ erlang-russia...@googlegroups.com.
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫: https://groups.google.com/groups/opt_out.
О©╫
О©╫

--
Yuri Zhloba

skype: yzh44yzh
jabber: yzh4...@gmail.com
phone: +375 44 793 33 73

--
--
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫: http://groups.google.com/group/erlang-russian
О©╫О©╫О©╫О©╫О©╫О©╫О©╫: http://erlanger.ru
О©╫О©╫О©╫: xmpp://erl...@conference.jabber.ru
О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫: xmpp://erlang...@conference.jabber.ru
О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫: http://erlanger.ru/ru/erlang-at-conference-jabber-ru
О©╫
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫: erlang-...@googlegroups.com
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫: erlang-russia...@googlegroups.com
---
О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ Erlang О©╫О©╫-О©╫О©╫О©╫О©╫О©╫О©╫.
О©╫
О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ erlang-russia...@googlegroups.com.
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫: https://groups.google.com/groups/opt_out.

[Max Lapshin]

Основная причина, чем erl -remsh хуже чем to_erl — это то, что в
случае каких-то проблем в логах существенно меньше информации о старте
системы.

Т.е. пока всё работает — без разницы. Как только что-то ломается с
этим -detach и remsh прыгаешь, прыгаешь, а причину выяснить сильно
сложнее, чем когда подсоединяешься с to_erl и смотришь.

Так же надо понимать, что не всё выдается в remote shell. Если есть
что-то, что пишет через io:format, то есть все шансы не получить этот
вывод.

[Daniil Churikov]

Несмотря на то, что тема называется "как деплоить без релизов", позвольте показать как это делать с релизами:

mkdir sample && cd sample/
rebar create-app appid=sample
mkdir rel && cd rel/
rebar create-node nodeid=sample
cd ..

Дальше создаём rebar.config (если его ещё нет):

cat rebar.config

{sub_dirs, ["rel"]}.

и немного полируем rel/reltool.config:
    Изменяем строчку
        {app, sample, [{mod_cond, app}, {incl_cond, include}]}
    добавляем секцию lib_dir в конец:
        {app, sample, [{mod_cond, app}, {incl_cond, include}, {lib_dir, ".."}]}

Теперь мы можем сделать:
    rebar generate
    ./rel/sample/bin/sample console

Определенно стоит потвикать файл reltool.config, у меня например не запускается релиз если не добавить в секцию sys

{app, hipe, [{incl_cond, exclude}]}, 
{app, wx, [{incl_cond, exclude}]},   
{app, webtool, [{incl_cond, exclude}]}

так же стоит почитать что вообще в этом файле можно писать например на lyse: http://learnyousomeerlang.com/release-is-the-word

Кстати, reltool предоставляет еще пару интересных плюшек, таких как шаблонизатор (см. overlay_vars), который поможет собрать релиз
в случае если у вас куча разных нод, напирмер вам нужно задать имя для каждой ноды по особому. Или подставить переменную в app.config


вторник, 13 августа 2013 г., 17:07:28 UTC+4 пользователь Alex Scherbanov написал:

[Денис Фахртдинов]

Я тут как раз ковыряюсь с riak_core, параллельно допиливая тестовое приложение. Собственно, вот: https://github.com/shizzard/erlcache.

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

2013/8/14 Daniil Churikov <ddo...@gmail.com>

--

[Alex Scherbanov]

Задал тот же вопрос на stackoverflow:

http://stackoverflow.com/questions/18242850/how-to-deploy-and-update-erlang-apps-without-releases

[Alex Bubnoff]

А собственно деплой? 

[Alex Scherbanov]

On Thursday, August 15, 2013 4:12:19 AM UTC+4, Alex Bubnoff wrote:

А собственно деплой? 

Wut? 

[Alex Bubnoff]

М. Кажется, стереть цитирование было плохой идеей. Вопрос был к Денису - он описал только сборку релиза, а не деплой.

четверг, 15 августа 2013 г., 17:18:27 UTC+7 пользователь Alex Scherbanov написал:

[Денис Фахртдинов]

Если вопрос адресовался мне, то ответа на него я не дам. ИМХО, деплой сильно зависит от специфики ваших задач. В одном случае вам подойдет тушение сервера на полчаса, сборка релиза на боевом сервере и запуск, а в другом вам будет нужно горячее обновление кода прямо в бою.
Мы обходились запаковкой релиза, его копированием на боевой сервер rsync'ом и последующим запуском. Система была толерантна к отключению одного бэкенда, а логика работы была построена на stateless запросах, поэтому обновление просто накатывалось на серверы одно за другим. Другое дело, что боевых серверов было всего четыре, поэтому деплой "вручную" не представлял из себя сложной задачи. В случае с сотней серверов такой подход бы не подошел.

2013/8/16 Alex Bubnoff <alex.b...@gmail.com>

--

Вы получили это сообщение, поскольку подписаны на группу Erlang по-русски.
 
Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес erlang-russia...@googlegroups.com.

Чтобы добавлять сообщения в эту группу, отправьте письмо по адресу erlang-...@googlegroups.com.

[Max Lapshin]

Я примерно описал: http://levgem.livejournal.com/445158.html

Думаю, делать сюда полную копипасту не стоит. Если есть какие вопросы — отвечу.

[Boris Timokhin]

Максим, статья интересная.

Возражать по существу не чему, кроме разве что, постановки вопроса и угла рассмотрения.

Во-первых хочу отметить, что ты рассматривашь только вариант пакетированного софта. Когда кто угодно скачивает и ставит где угодно (вплоть до винды и андроидов). Замечу, что с этим в erlang вообще плохо. Нет инструментов. Нужны годы и тысячи подобных проектов, которые бы развивали технологию "тут сейчас запаковал, заработает где хочешь". А глядя, например, на тот же python, в котором уже давно тысячи пакетов и туча систем сборки и разворачивания - по-прежнему "взял и заработало" можно увидеть только под ubuntu и на довольно простых библиотеках.

А пакетированное erlang решение это всё-таки редкость - ты их всех и перечислил. И бурно развиваться это наврядли будет.

В 95% erlang-разработка это всё-таки проектное решение в ограниченном пространстве. И если присутствует какой-то пакетирование и распространение, то все точно знают где оно будет запускаться и могут настроить всё окружение вокруг. Релизы для этих парней, которые точно знают какой будет glibc, какая ось, какая версия erlang на целевой машине. И только для них.

Во-вторых. Тезис о том, что мир хрупок, и всё может, ВНЕЗАПНО, закончиться, конечно же неоспоримый. Но мне кажется, заблуждение филосовского уровня, пытаться найти программное решение проблеме уничтожения сервера. Не встречал ни разу позиционирования релизов, как решения бесперебойной работы (я имею в виду авторитетного мнения). Это та штука, которая помогает, если добавил ещё один клоз к функции, то "всунуть" его на работающий сервер, чтобы не стопать лишний раз, а не та штука, которая будет хранить денежные транзакции в памяти даже при пулеметной атаке. Человек должен помнить, о том что он смертен, всегда. И всегда планировать сохранность данных. Релизы тут не помогают и не мешают. Но соглашусь - в обществе витает это заблуждение. Проблема не в том, что инструмент не серебрянная пуля, а в том, что люди нервно пытаются его таким представить.

Вопрос стейтов. Начнём с того, что структура стейтов всё-таки меняется довольно редко. Смена структуры стейтов, чем-то схожа с миграцией схемы БД. Работали месяцами, и вот решили, что надо пользователю добавить поле/колонку ... avatar. Тут рекомендаций несколько и они известны. Рекорд стоит использовать ровно в одном модуле, использовать API для работы с ним из других, а если это стейт процесса (gen_server), то просто добавляется клоз в code_change, который обрабатывает "старый" рекорд. Если по каким-то причинам всё сложнее и требует ресурсов огромных, для реализации апдейта, то дешевле может оказаться "моргнуть". Релизы не запретят это делать, просто раз в два месяца может оказаться так, что инструмент бессилен.

Проверка правильности обновления, как в других технологиях ложится на плечи CI. Закоммитили, CI собрал, обновил, прочекал, если всё плохо - все узнали через 10 минут о том, что в последнем коммите написали неправильный code_change.

Моё мнение.

1. Если вы не поставляете софт в неизвестное окружение, то релизы, как минимум удобны просто в rebar generate. И start/stop/attach

2. Релизы, даже с ребаром не помогут скачку напряжения сохранить ваши ets-таблицы на диск.

3. "Серьёзные" обновления состояния случаются редко. Я имею в виду, когда уже стабильная версия и мы в продакшене, конечно.

4. Даже, если вы побаиваитесь использовать апдейты, или "для начала", вы можете просто удалять старый релиз, останавливать и запускать новый.

5. Используйте CI. Хорошо сконфигурированный CI экономит много рутинных проверок и добавляет уверенности.

17 августа 2013 г., 8:51 пользователь Max Lapshin <max.l...@gmail.com> написал:

Я примерно описал: http://levgem.livejournal.com/445158.html

Думаю, делать сюда полную копипасту не стоит. Если есть какие вопросы — отвечу.

--

[Boris Timokhin]

Максим, статья интересная.

Возражать по существу не чему, кроме разве что, постановки вопроса и угла рассмотрения.

Во-первых хочу отметить, что ты рассматривашь только вариант пакетированного софта. Когда кто угодно скачивает и ставит где угодно (вплоть до винды и андроидов). Замечу, что с этим в erlang вообще плохо. Нет инструментов. Нужны годы и тысячи подобных проектов, которые бы развивали технологию "тут сейчас запаковал, заработает где хочешь". А глядя, например, на тот же python, в котором уже давно тысячи пакетов и туча систем сборки и разворачивания - по-прежнему "взял и заработало" можно увидеть только под ubuntu и на довольно простых библиотеках.

А пакетированное erlang решение это всё-таки редкость - ты их всех и перечислил. И бурно развиваться это наврядли будет.

В 95% erlang-разработка это всё-таки проектное решение в ограниченном пространстве. И если присутствует какой-то пакетирование и распространение, то все точно знают где оно будет запускаться и могут настроить всё окружение вокруг. Релизы для этих парней, которые точно знают какой будет glibc, какая ось, какая версия erlang на целевой машине. И только для них.

Во-вторых. Тезис о том, что мир хрупок, и всё может, ВНЕЗАПНО, закончиться, конечно же неоспоримый. Но мне кажется, заблуждение филосовского уровня, пытаться найти программное решение проблеме уничтожения сервера. Не встречал ни разу позиционирования релизов, как решения бесперебойной работы (я имею в виду авторитетного мнения). Это та штука, которая помогает, если добавил ещё один клоз к функции, то "всунуть" его на работающий сервер, чтобы не стопать лишний раз, а не та штука, которая будет хранить денежные транзакции в памяти даже при пулеметной атаке. Человек должен помнить, о том что он смертен, всегда. И всегда планировать сохранность данных. Релизы тут не помогают и не мешают. Но соглашусь - в обществе витает это заблуждение. Проблема не в том, что инструмент не серебрянная пуля, а в том, что люди нервно пытаются его таким представить.

Вопрос стейтов. Начнём с того, что структура стейтов всё-таки меняется довольно редко. Смена структуры стейтов, чем-то схожа с миграцией схемы БД. Работали месяцами, и вот решили, что надо пользователю добавить поле/колонку ... avatar. Тут рекомендаций несколько и они известны. Рекорд стоит использовать ровно в одном модуле, использовать API для работы с ним из других, а если это стейт процесса (gen_server), то просто добавляется клоз в code_change, который обрабатывает "старый" рекорд. Если по каким-то причинам всё сложнее и требует ресурсов огромных, для реализации апдейта, то дешевле может оказаться "моргнуть". Релизы не запретят это делать, просто раз в два месяца может оказаться так, что инструмент бессилен.

Проверка правильности обновления, как в других технологиях ложится на плечи CI. Закоммитили, CI собрал, обновил, прочекал, если всё плохо - все узнали через 10 минут о том, что в последнем коммите написали неправильный code_change.

Моё мнение.

1. Если вы не поставляете софт в неизвестное окружение, то релизы, как минимум удобны просто в rebar generate. И start/stop/attach

2. Релизы, даже с ребаром не помогут скачку напряжения сохранить ваши ets-таблицы на диск.

3. "Серьёзные" обновления состояния случаются редко. Я имею в виду, когда уже стабильная версия и мы в продакшене, конечно.

4. Даже, если вы побаиваитесь использовать апдейты, или "для начала", вы можете просто удалять старый релиз, останавливать и запускать новый.

5. Используйте CI. Хорошо сконфигурированный CI экономит много рутинных проверок и добавляет уверенности.

17 августа 2013 г., 8:51 пользователь Max Lapshin <max.l...@gmail.com> написал:

Я примерно описал: http://levgem.livejournal.com/445158.html

Думаю, делать сюда полную копипасту не стоит. Если есть какие вопросы — отвечу.

--

[Boris Timokhin]

Максим, статья интересная.

Возражать по существу не чему, кроме разве что, постановки вопроса и угла рассмотрения.

Во-первых хочу отметить, что ты рассматривашь только вариант пакетированного софта. Когда кто угодно скачивает и ставит где угодно (вплоть до винды и андроидов). Замечу, что с этим в erlang вообще плохо. Нет инструментов. Нужны годы и тысячи подобных проектов, которые бы развивали технологию "тут сейчас запаковал, заработает где хочешь". А глядя, например, на тот же python, в котором уже давно тысячи пакетов и туча систем сборки и разворачивания - по-прежнему "взял и заработало" можно увидеть только под ubuntu и на довольно простых библиотеках.

А пакетированное erlang решение это всё-таки редкость - ты их всех и перечислил. И бурно развиваться это наврядли будет.

В 95% erlang-разработка это всё-таки проектное решение в ограниченном пространстве. И если присутствует какой-то пакетирование и распространение, то все точно знают где оно будет запускаться и могут настроить всё окружение вокруг. Релизы для этих парней, которые точно знают какой будет glibc, какая ось, какая версия erlang на целевой машине. И только для них.

Во-вторых. Тезис о том, что мир хрупок, и всё может, ВНЕЗАПНО, закончиться, конечно же неоспоримый. Но мне кажется, заблуждение филосовского уровня, пытаться найти программное решение проблеме уничтожения сервера. Не встречал ни разу позиционирования релизов, как решения бесперебойной работы (я имею в виду авторитетного мнения). Это та штука, которая помогает, если добавил ещё один клоз к функции, то "всунуть" его на работающий сервер, чтобы не стопать лишний раз, а не та штука, которая будет хранить денежные транзакции в памяти даже при пулеметной атаке. Человек должен помнить, о том что он смертен, всегда. И всегда планировать сохранность данных. Релизы тут не помогают и не мешают. Но соглашусь - в обществе витает это заблуждение. Проблема не в том, что инструмент не серебрянная пуля, а в том, что люди нервно пытаются его таким представить.

Вопрос стейтов. Начнём с того, что структура стейтов всё-таки меняется довольно редко. Смена структуры стейтов, чем-то схожа с миграцией схемы БД. Работали месяцами, и вот решили, что надо пользователю добавить поле/колонку ... avatar. Тут рекомендаций несколько и они известны. Рекорд стоит использовать ровно в одном модуле, использовать API для работы с ним из других, а если это стейт процесса (gen_server), то просто добавляется клоз в code_change, который обрабатывает "старый" рекорд. Если по каким-то причинам всё сложнее и требует ресурсов огромных, для реализации апдейта, то дешевле может оказаться "моргнуть". Релизы не запретят это делать, просто раз в два месяца может оказаться так, что инструмент бессилен.

Проверка правильности обновления, как в других технологиях ложится на плечи CI. Закоммитили, CI собрал, обновил, прочекал, если всё плохо - все узнали через 10 минут о том, что в последнем коммите написали неправильный code_change.

Моё мнение.

1. Если вы не поставляете софт в неизвестное окружение, то релизы, как минимум удобны просто в rebar generate. И start/stop/attach

2. Релизы, даже с ребаром не помогут скачку напряжения сохранить ваши ets-таблицы на диск.

3. "Серьёзные" обновления состояния случаются редко. Я имею в виду, когда уже стабильная версия и мы в продакшене, конечно.

4. Даже, если вы побаиваитесь использовать апдейты, или "для начала", вы можете просто удалять старый релиз, останавливать и запускать новый.

5. Используйте CI. Хорошо сконфигурированный CI экономит много рутинных проверок и добавляет уверенности.

17 августа 2013 г., 8:51 пользователь Max Lapshin <max.l...@gmail.com> написал:

Я примерно описал: http://levgem.livejournal.com/445158.html

Думаю, делать сюда полную копипасту не стоит. Если есть какие вопросы — отвечу.

--

[Max Lapshin]

> Начнём с того, что структура стейтов всё-таки меняется довольно редко. 

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

В моей практике in-house проектов это происходит несколько раз за день.

В том числе меняются и данные в ets таблицах, которые так же надо в code_change пересчитывать.

[Maxim Sokhatsky]

Очень хороший ответ :)

Мы любим релизы я ивляемся адвокатами и апологетами релизов.

Единственная их проблема -- это скорость сборки при

разработке и необходимость перерелизивания.

Это проблему частично пытался решить Люик с

помощью erlang.mk, но и мы ее решили по-своему.

Как? Отвечу также Сергею Абрамяну, поскольку у Лапшина в ЖЖ мои

комментарии модерируются сутками.

https://github.com/voxoz/release_server/blob/master/Makefile.run

https://github.com/voxoz/release_server/blob/master/envgen.erl

Мы тоже как erlang.mk используем дерево релтула,

но при этом мы може запускать не релизом, а используем

релтул только для валидации. Ну и полезно в девелопмент

режиме инжектить-удалять модули и все такое.

Т.е. оно совместимо и с erlang.ml и с rebar -f configure.

То, что Лапшину не подошли релизы не означает,

что все должны их быстро бросить.

---

Date: Sat, 17 Aug 2013 12:42:11 +0400
Subject: Re: расскажите, как деплоить без релизов
From: mathe...@gmail.com
To: erlang-...@googlegroups.com

[Boris Timokhin]

Вполне может быть. Тогда конечно не удобно полдня писать новый стейт, а потом ещё полдня appup под это дело и так каждый день.

Но много ли таких организаций, где уже в продакшене, а не на стадии креатива, несколько раз в день меняют СТРУКТУРУ стейтов?

Мы может про разные вещи говорим? 

Я предпочитаю такой подход:

Например имеем таблицу/стейт пользователя. Выделяем структурно-необходимые поля, с которыми активно работаем, на которых строится логика, а всё "справочное" уходит в отдельное поле (proplist). Имеем у пользователя id, name, some_datetime, param1, param2, other. Когда нам надо добавить "цвет глаз", и к этому "цвету глаз" не идёт два экрана логики и индексов, а будет использоваться в слое отображения, то пусть он просто лежит в проплисте other и не надо трогать рекорды и не надо на это никаких appup. 

А если мы каждый день будем добавлять к пользователю по два поля, то сколько полей будет через месяц?

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

PS: Надеюсь теперь один раз отправится, прошу прощения за прошлый трипл.

17 августа 2013 г., 12:42 пользователь Max Lapshin <max.l...@gmail.com> написал:

[Sergey Abramyan]

Ну Макс рассказал о конкретной проблеме, у него же задача деплоиться на много разных систем. А когда ты знаешь какое у тебя будет окружение и сам его настраиваешь, нет причин, по которым не стоит использовать релизы.

2013/8/17 Maxim Sokhatsky <ma...@synrc.com>

--

С уважением,

Сергей Абрамян

[Max Lapshin]

Тут дело такое, что я ни от одного «апологета» релизов не видел ещё ни одного внятного комментария на тему того, как решать описанные мной проблемы и зачем вообще решать те проблемы, которые релизы создают.

Поэтому я вынужден просто пропускать мимо ушей всю эту болтовню.

[Maxim Sokhatsky]

Я думал над его проблемой как ее решить в рамках релизов.

И у меня только такие варианты:

1. Иметь три версии Эрланга под все платформы

    Windows, Linux, Mac на каких-то внешних машинах.

2. Настроить релтул так, что бы забирать по SSH эти

    версии при включении в релиз.

Можно, как вариант, еще иметь три билд сервера.

Но даже если релизы не подошли -- это не повод

уходить от OTP сткрутуры каталогов и терять

совместимость с многими системами сборки.

---

Date: Sat, 17 Aug 2013 14:01:03 +0400

Subject: Re: расскажите, как деплоить без релизов

From: sa.ab...@gmail.com
To: erlang-...@googlegroups.com

[Maxim Sokhatsky]

Я могу решить все твои проблемы.

---

Date: Sat, 17 Aug 2013 14:05:34 +0400

Subject: Re: расскажите, как деплоить без релизов

From: max.l...@gmail.com
To: erlang-...@googlegroups.com

Тут дело такое, что я ни от одного «апологета» релизов не видел ещё ни одного внятного комментария на тему того, как решать описанные мной проблемы и зачем вообще решать те проблемы, которые релизы создают.

Поэтому я вынужден просто пропускать мимо ушей всю эту болтовню.

[Sergey Abramyan]

Но это не так удобно. Держать еще кучу машин для сборки, когда ты от этого получаешь сомнительные плюсы. Появится новая система у клиента, и надо будет снова поднимать виртуалку под это дело - муторно слишком и потеря времени. Но опять же, говорим про конкретный случай.

2013/8/17 Maxim Sokhatsky <ma...@synrc.com>

[Maxim Sokhatsky]

Как это появится еще одна система ? Солярис восстанет из пепла ?

---

Date: Sat, 17 Aug 2013 14:10:26 +0400

[Sergey Abramyan]

Нет конечно =)

Я говорю про окружение и версии пакетов. Привели уже пример про glibc, ssl.

2013/8/17 Maxim Sokhatsky <ma...@synrc.com>

[Maxim Sokhatsky]

Ну какая разница из какого места тащить Эрланг ?

---

Date: Sat, 17 Aug 2013 14:15:08 +0400

[Sergey Abramyan]

Так вроде в статье все раскрыто, не? Удобство же, когда на твоей же машине, все необходимо окружение и тут же ты все собрал. Я думаю дальше обсуждать нет смысла, у каждого останется свое мнение.

2013/8/17 Maxim Sokhatsky <ma...@synrc.com>

[Maxim Sokhatsky]

Мой пойнт в том, что можно запаковать Эрливидео и в релизах,

это вообще не принципиально, которые будут деплоиться

на все платформы и это будет не сложнее, чем у Эрливидео.

Максим сделал без релизов -- ок, в его случае 

релизы -- это дополнительный трейд-офф на который он не пошел.

Вот и все.

---

Date: Sat, 17 Aug 2013 14:18:44 +0400

[Boris Timokhin]

Максим, если ты про конкретно erlyvideo, то твой опыт уникален. Я, лично, не могу тебе ничего посоветовать.

И не могу сказать, как бы я это делал с релизами. Релизы просто собирают проект, они не решают проблемы кросс-платформенности и криворукости людей на "том" сервере.

Я нигде не видел, чтобы, кто-то описывал, как собрать с релизами кросс-платформенное решение. Это крайне-редкая задача в эрланг-мире.

Но ТС, как и подавляющая часть рассылки деплоят, или собираются деплоить не коробочное решение, а связку из десятка приложений на свои собственные сервера. Твой опыт просто не релевантен топику. Ты решаешь ДРУГУЮ проблему, которую мало кому доведётся решать. И крайне мало кто сталкивается с описанными тобой проблемами.

Никто не думает - "а как себя поведёт моя сборка под R14 на CentOS".

Для большинства, rebar geberate делает всё что нужно, не создавая, вообще никаких проблем.

17 августа 2013 г., 14:05 пользователь Max Lapshin <max.l...@gmail.com> написал:

Тут дело такое, что я ни от одного «апологета» релизов не видел ещё ни одного внятного комментария на тему того, как решать описанные мной проблемы и зачем вообще решать те проблемы, которые релизы создают.

Поэтому я вынужден просто пропускать мимо ушей всю эту болтовню.

[Max Lapshin]

Борис, если бы ты внимательно прочитал мой пост, увидел бы что ты неправ.

У меня не только эрливидео, есть и другие проекты, которые я выкатываю себе.

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

При этом _никаких_ обсуждений озвученных мной проблем нет.

Лично меня это заебало =)

[Maxim Sokhatsky]

Запаковать тебе Эрливидео в релизе под три платформы ?

---

Date: Sat, 17 Aug 2013 15:03:50 +0400

Subject: Re: расскажите, как деплоить без релизов

From: max.l...@gmail.com
To: erlang-...@googlegroups.com

[Alex Scherbanov]

Спасибо, Макс, интересно. У всех подходов пока есть недостатки, буду все пробовать.