Release Kamasutra

[m_a_m_o_n]

С прошлого раза когда я писал про Continuous Deployment
прошло около года и где то 150 релизов.


1. Совершенно не важно что деплоить, важно как деплоить.

2. Release и Deploy это совершенно разные вещи.
-- Deploy - это перетаскивание изменений на продакш сервера.
-- Release - переключения пользователя на код с изменениями.
-- Release Undo - это must-have.

Так вот, Release действительно должен делаться одной кнопкой,
и одной же кнопкой откатываться. С точки зрения автоматизации
деплоя release должен быть реально одной простой командой
(не скопировать файлики сюда, положить варку туда, обновить базу,
запустить сервер, что нибудь ещё по вкусу и желанию) - одна
команда это переключить http-proxy на сервер(а) с новой версией кода
(undo - переключить http-proxy обратно).

Deploy - это не только изменение конфигурации серверов,
изменние структуры базы, развёртывание war-ки с новой версией
приложения - но ещё и _проверка_ изменений перед выкаткой
их пользователю. Все все все шаги которые здесь есть
должны делаться так что бы пользователь об этом не знал.

3. Приложение должно быть реально stateless. Буквально.
Сессия должна быть stateless (никаких request.getSession(), см. play)
Если приложение нужны JMS очереди или что угодно что хранит состояние - они
должны быть вынесены в standalone сервисы.
Хранимки зло, вьюхи зло.

4. Все изменения инфраструктуры должны версионироваться.
Изменения базы, например через migrate.
Изменения в конфигурации, например через puppet.

5. Дифференциальный анализ логов (сколько и каких ошибок было "вчера", сколько и каких "сегодня",
какие появились новые, какие ушли) и мониторинг после релиза.

6. Ответственные должны присутствовать при релизе лично.

7. Деплой кода выполняемого по расписанию это отдельный жанр (todo).