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

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

По-моему, в статье описан очень частный случай подготовки и проведения релиза какого-то очень большого монолита (понимаю, что это личный опыт и обстоятельства автора). В мире микросервисов, к примеру, обычно совсем всё не так — там задолбаешься по 20 раз в день назначать «ответственного» и «делать таблицы в вики». Такие глобальные релизы — не всегда хорошо. Мое мнение — надо стремиться к бОльшей частоте релизов, но ни в коем случае не жертвовать при этом качеством продукта.

Кстати, «Релиз одной кнопкой» — давно уже не миф, а вполне себе ожидаемая реальность на проектах, где действительно работает концепт «DevOps».

Отчасти согласен, но микросервисы и большие релизы не исключают друг друга.


Может в идеале любой микросервис (включая "микроuiи") и должен деплоиться всегда независимо и обеспечивать полную совместимость как прямую, так и обратную, причём проверка совместимости быстрая и надёжная. Но на практике, по-моему, это встречается редко, потому что очень дорого при сколь-нибудь крупном продукте.


Чаще встречается ситуация когда микросервисы есть, но деплоятся они пачками: добавили/изменили пачку связанных в фичу/стори ендпоинтов в нескольких сервисах, соответственно добавили/изменили uiи и деплоим всё пачкой, потому что регресс-тестирование долго идёт и проводить его на всей системе для, грубо говоря, каждого коммита в каждом сервисе и ui долго.


Например, фича явно затронула (изменила код) трех сервисов и двух ui явно. Пускай даже можно деплоить сервисы и ui по очереди с промежутками в дни. Но после подготовки каждого деплоя нужно проводить полный регресс всей системы из пары десятков сервисов и пятка ui, который длится например день. Если деплоить независимо то это пять дней на тестирование одной фичи. Если деплоить пачкой, то один день. Но если пачкой, то нужно уже управлять релизом, обеспечить, чтобы 5 "коммитов" от разных людей/команд вылились одновременно или почти одновременно

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории