Все верно, страшно поломать, потому миграции - это отдельная задача, выполняется силами SRE. Ведь разница с API'шкой, выкатывающейся автоматически, в том, что ее откат - это почти стопроцентная уверенность в восстановлении сервиса в случае проблемного релиза, а со stateful дела обстоят точно наоборот.
Да и в целом миграции в нашем случае - очень редкая история.
Тестирование каждой задачи производится на индивидуальных дев-стендах разработчиков полными регрессами во время разработки этой самой задачи. Так мы убеждаемся, что "компоненто" все ок.
Далее собирается в релиз набор изменений из нескольких задач — во время сборки прогоняются лишь юниты (так убеждаемся, что мерж-конфликты банально не поломали код), после чего собранный образ заливается на стейджинг k8s (уже пайплайном) для проверки возможности подняться сервису в целом и провести инициализацию (ожидаем статус Ready у деплоймента).
Регрессионное тестирование стенда с уже собранным релизом не предусмотрено. Но чтобы нивелировать риск выкатить нерабочий код на большой % пользователей предусмотрена постепенная плавная раскатка, во врем которой контролируются основные метрики приложения (как продуктовые, так и технические).
Информация
В рейтинге
Не участвует
Зарегистрирован
Активность
Специализация
DevOps-инженер, Архитектор программного обеспечения
Все верно, страшно поломать, потому миграции - это отдельная задача, выполняется силами SRE. Ведь разница с API'шкой, выкатывающейся автоматически, в том, что ее откат - это почти стопроцентная уверенность в восстановлении сервиса в случае проблемного релиза, а со stateful дела обстоят точно наоборот.
Да и в целом миграции в нашем случае - очень редкая история.
Добрый. Все так, поправил, спасибо!
Тестирование каждой задачи производится на индивидуальных дев-стендах разработчиков полными регрессами во время разработки этой самой задачи. Так мы убеждаемся, что "компоненто" все ок.
Далее собирается в релиз набор изменений из нескольких задач — во время сборки прогоняются лишь юниты (так убеждаемся, что мерж-конфликты банально не поломали код), после чего собранный образ заливается на стейджинг k8s (уже пайплайном) для проверки возможности подняться сервису в целом и провести инициализацию (ожидаем статус Ready у деплоймента).
Регрессионное тестирование стенда с уже собранным релизом не предусмотрено. Но чтобы нивелировать риск выкатить нерабочий код на большой % пользователей предусмотрена постепенная плавная раскатка, во врем которой контролируются основные метрики приложения (как продуктовые, так и технические).