Чем отличается CI/CD в Amazon и Google?

Интересная статья о том, насколько различен подход к CI/CD у двух IT-гигантов. В компаниях такого размера и с таким темпом поставки фич на прод любая мелочь имеет значение, а уж процесс организации этой поставки — и подавно.

Ведь недостаточно просто “прогнать тестики” — нужно полноценно убедиться, что код работает и новый релиз ничего не сломал. А если и сломал, то должна быть возможность это быстро починить. Поэтому стоит подсмотреть, как организованы процессы CI/CD в этих известных бигтехах.

Интересные идеи

Google использует монорепу, Amazon — микро-репы (каждый сервис лежит в отдельном репозитории). Это важно, потому что от структуры отталкивается весь дальнейший процесс.

Из-за того, что Google использует монорепу, они сильно вложились в инфраструктуру автотестов. На таком количестве разработчиков в одной репе любая проблема может обернуться катастрофой. Однако фаза выкатки на прод у них страдает — после мержа изменения доедут на прод не скоро. Причина заключается в том, что один code change может вызвать тысячи деплоев, поэтому быстрая выкатка — непозволительная роскошь.

В Amazon всё ровно наоборот: разделение на микро-репы позволяет командам не так сильно вкладываться в инфраструктуру автотестов. Влияние ошибки ограничено, поэтому работать становится более безопасно. Благодаря этому Amazon сильно вложились в post-submit фазу: от мержа кода до выкатки на прод проходят часы, а не дни или недели.

Как правильно? А никак — it depends. Google много вложили в инфраструктуру автотестов, Amazon не меньше вложили в инфраструктуру управления репозиториями и командами.

В конце автор приходит к выводу, что нужно инвестировать силы и в pre-submit, и в post-submit фазу. К сожалению, это утопия — слишком дорого даже для бигтехов.

Приятного чтения!

#highload@tech_fit
➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи