Deployment
Зачем
Как обновлять кодовую базу незаметно для пользователей:
- возможности управления HAProxy и реализации Graceful Shutdown в наших сервисах
- Миграции бд
- поддерживаем на бою одновременно старую и новую версии сервиса применяя стратегии развертывания
- Заранее, на этапе разработки софта, закладывается версионирование, что даже если будут изменения в базе данных сервиса, они не будут ломать предыдущий код
Версионирование обновлений приложения
- Цель
- Не зависеть от обновлений бэка. Бэк выкатывается раньше.
- Обратная совместимость
- Простота поддержки
- Минимальное время простоя
- Проблемы
- Пользователь не обновляется
- Проверка долго, могут не пустить версию
- Новая версия приложения еще неработает, а бэк новый уже обновлен
- Версионирование варианты
- Mediator pattern
- Expand contract избыточность кода, поддержка документации
- Номер версии: В данных, api - url, header
- Правила версионирования SemVer
- Язык запрсов к API: Graphql
- Unit tests api version
Стратегии развертывания Deploy
- Надежность
- Rollback pattern
- Blue Green Deployment
- k8s
- Recreate - с простоем
- Rolling Update - запускает новые поды параллельно с запущенными старыми, а затем убивает старые, и оставляет только новые
- Rollback pattern
- Сокращение TTM, проверка гипотез
- Canary Deployment
- Dark (скрытые) или А/В-развертывания - вариация Canary стратегии . Разница между скрытым и канареечным развертыванием (Canary Deployment) состоит в том, что скрытые развертывания имеют дело с фронтендом, а не с бэкендом, как канареечные.
- Ref Arch A\B test
- Feature toggle
- варианты
Canary Deployment
- Canary Deployment - гибче Rolling Update, т.к. часть запросов переключается на новую версию, а часть продолжает использовать старую версию
- TODO нюансы
- Reference arch Oracle