Сине-зеленый деплой

[kossmak]

С базами данных при таком подходе часто бывают проблемы

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

[beastea]

А ссылку на оригинал статьи можно приложить?

[freetonik]

На Хабре у постов-переводов ссылка на оригинал есть в самом низу статьи, в блоке с мета-информацией.

Вот → http://martinfowler.com/bliki/BlueGreenDeployment.html

[beastea]

спасибо. не сразу и найдешь.

[proshin]

Трюк с использованием одной базы данных для двух серверов с разными версиями приложения заключается в том, что в новых версиях можно только добавлять новые сущности (колонки, таблицы и т.д.). А удалять старые можно только после того, как все серверы мигрируют на новую версию. При этом ничего не мешает делать это из самого приложения (обновление БД при запуске приложения — Liquibase и т.д.). Недостаток: миграция БД занимает несколько версий приложения.

А вот использование разных баз данных обязательно приведет к вопросу их синхронизации между собой, что опять-таки должно выполняться автоматически. Первый вариант (одна БД — много серверов) выглядит проще и надежнее.

[shushu]

Основная идея в том, чтобы иметь две легко переключаемых среды

А что если если серверов много? Достаточно дорогое решение. Ко всему этому 50% мощности всегда простаивает.

[shushu]

Да и необходимость переводить приложение в read-only режим во время деплоя тоже не очень красивое решение.

[osigida]

Большие дядьки, когда серверов много, заменяют по одному контролируя кто из пользователей переключен на новый сервис. canary release называется, опять же у Фаулера почитать можно: http://martinfowler.com/bliki/CanaryRelease.html
что в общем то частный случай blue-green deployemnt-а

Переключать в read-only не нужно и даже вредно, но нужно соблюдать правила backward/forward compatibity.
и снова Фаулер к чтению: http://martinfowler.com/articles/consumerDrivenContracts.html

[orgkhnargh]

По-вашему, 50% дисков в RAID1 тоже простаивают?

[onyxmaster]

Здесь вам на помощь придёт уменьшение уровня изоляции — виртуальные машины, контейнеры или даже просто изолированные среды исполнения (отдельные application pool в IIS, pool в php-fpm и т.д.).
Например у нас более-менее стандартная схема nginx->haproxy->backend, где в качестве бэкендов выступают IIS, где на каждом сервере есть b/g apppool. Основная нагрузка обрабатывается только одним экземпляром, второй через минуту (в нашем случае) просто выгружается, потому что haproxy не передаёт на него новых запросов. А запас по памяти на бэкенде организовать обычно не проблема.

[Maur]

Прежде всего хочу сказать спасибо моей жене Клэр, которая сподвигла меня написать это комментарий. Моим друзям Дэну и Стивену что поддерживали меня когда я читал текст перевода. Хочу поблагодарить Натали Басс за оказаный перевод, и особую благодарность Дэйву Фарли (Dave Farley) и Джезу Хамбл (Jez Humble) за незаконченную книгу «Непрерывная доставка», автору неизвестного рисунка с амебами, так же благодарен за то что открыл для меня новый вид технической схемы.

После того как мы пересели на Сине-Зеленый деплой мы увеличили продажи. Вначале мы были настроены скептически, но когда мы собравшись на совещании, Кен (наш ведущий аналитик) неожиданно сказал: «Почему бы нам не попробувать сине-зеленый деплой»? И тут же с жестикуляцией начал объяснять нам, что это то, что нам нужно. Никогда наши совещания не были столь увлекательные. Мы избежали сразу же проблемы с базами данных с маржинколами и перчерсордерами, фьючерсы начали общатся на одном языке с контентменеджерами, а фолоапы почти исчезли.

Спасибо автор за проделаный вами труд. Побольше бы таких статей на хабре!

PS: Спасибо фаулеру за новый паттерн!

[AlexBin]

Прям не иллюстрации, а реклама детских разноцветных прокладок.