Как стать автором
Обновить

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

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

Кто бы сомневался)
Печаль в том, что со временем все привыкают бояться задорого менять имеющиеся и закостеневшие сущности в БД, без страха только приносят новые.
А ссылку на оригинал статьи можно приложить?
На Хабре у постов-переводов ссылка на оригинал есть в самом низу статьи, в блоке с мета-информацией.

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

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

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

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

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

Здесь вам на помощь придёт уменьшение уровня изоляции — виртуальные машины, контейнеры или даже просто изолированные среды исполнения (отдельные application pool в IIS, pool в php-fpm и т.д.).
Например у нас более-менее стандартная схема nginx->haproxy->backend, где в качестве бэкендов выступают IIS, где на каждом сервере есть b/g apppool. Основная нагрузка обрабатывается только одним экземпляром, второй через минуту (в нашем случае) просто выгружается, потому что haproxy не передаёт на него новых запросов. А запас по памяти на бэкенде организовать обычно не проблема.
Прежде всего хочу сказать спасибо моей жене Клэр, которая сподвигла меня написать это комментарий. Моим друзям Дэну и Стивену что поддерживали меня когда я читал текст перевода. Хочу поблагодарить Натали Басс за оказаный перевод, и особую благодарность Дэйву Фарли (Dave Farley) и Джезу Хамбл (Jez Humble) за незаконченную книгу «Непрерывная доставка», автору неизвестного рисунка с амебами, так же благодарен за то что открыл для меня новый вид технической схемы.

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

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

PS: Спасибо фаулеру за новый паттерн!
Прям не иллюстрации, а реклама детских разноцветных прокладок.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории