А кто как организует у себя процесс непрерывного развертывания приложений?


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

Понятно, что бизнес желает подсунуть технарям время для даунтайма между 1-3 ночи. Понятно что технари против.

Отсюда и рождается вопрос. Возможно ли обойтись вообще без downtime?
Так чтобы и манагеры не плакали и так чтобы деплой делался днем.

Да, простые выкладки проходят и днем без проблем. Сложности возникают как правило при деплое завязанном на изменение схемы БД. Там часто бывает так что не только схема меняется, но и сами данные, что занимает время. Часы.


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

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


Кто какие схемы применяет?
Какие встречал подводные камни?

Есть готовые решения?

svenom,

к сожалению, даже на предпроде не всегда получается получить такую же ситуацию как на боевом.

дело в окружении. часто в конфигах и т.д.

под тестингом на боевом я имел ввиду только самые необходимые шаги. буквально, что оно встало и пашет.

говорят GAE как то умеет обеспечивать версионность приложений. я думал есть инструменты похожие и в Java EE

Спасибо. У оракла есть решение на самом сервере приложений. Разные стратегии деплоя. Неплохо. Здорово их описали. Спасибо подумаем)).

Осталось только с версионностью базы решить.

Есть такая идея.

Если изменяется структура БД, то не альтерить текущие таблички. Оставить их в покое.
Всегда создавать новые + скрипт копирования данных из старых в новых.

Тогда можно начинать деплой БД отдельно от деплоя приложения и к тому же не останавливая работу.

Есть только одна проблема - внешние ключи. и запросы к изменяемой табличке.

И если запросы легко инкапсулируются в случае использования NamingQuery -JQL + достаточно будет поменять только одну Entity, которая кстати и так и так будет переделана в новую версию как минимум по структуре, то с внешними ключами сложнее.

1. С одной стороны их можно не создавать. но тогда придется этот контроль отдавать в сервер приложений. Довериться ему. А это чревато. Накосячить могут сами прогеры. Работа с ключами, связями, целостностью отлажена в любом движке СУБД до блеска и по скорости и по качеству.

2. А можно применив хук в структуре БД .

Как вам такой вариант. Это будет как стратегия создания сущностей с поддержкой реалтайм обновления структур.

Определимся что у каждой сущности всегда должен быть первичный ключ. Суррогат.
Для каждой сущности, которая может иметь внешние ключи делаем структуру из двух таблиц с идентифицирующей связью 1:1.

Первая таблица MasterTable содержит только ПК и никаких других полей.
Вторая таблица DetailTable содержит внешний ключ на эту табличку, который в свою очередь тоже ПК.
Все атрибуты хранятся в DetailTable.

Т.е. условно это как бы одна табличка. что-то типа кластера.

Все таблички которым нужен внешний ключ строят его на MasterTable.
Т.е. DetailTable всегда свободна от внешних ключей на нее.

Теперь если нам нужно дополнить или поменять атрибутивный состав DetailTable мы создаем табличку DetailTable_v2 и для нее накатываем новый Entity. Убедившись что скрипт копирования данных отработал успешно, то удаляем старую DetailTable.

Cами по себе Detail могут содержать внешние ключи на другие сущности помимо своей Master. Но эти внешние ключи тоже будут исключительно на их MasterTable_<Other>. Т.е. они тоже всего лишь атрибуты.

Про связи многие ко многим не думал пока. Но по сути это всегда тоже отдельная таблица и она сама по себе легко меняется на новую версию. Для таблицу связей M:N мастер не нужен будет.


Ну как? Бред?

Кореец,

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

т.е. это сразу вылезет. Такие ошибки легко поправятся до тестов.


А если совсем уж зафантизироваться то можно в реляционке хранить основные связи, а сами значения атрибутов в KeyValue базе. NoSQL.

Понятно что тогда джойнов от внешних ключей с Detail не получится. Ну и не надо. Там простейшими отдельными запросами по этим ключам к тоже NoSQL очень быстро отработает.