Подкачивай хард-скиллы и держи техническую форму с регулярными разборами ключевых IT материалов: архитектура, базы данных, производительность и системный дизайн.
По всем вопросам и рекламе: @NikitaUlshin
Post #19
398
Чем отличается 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
➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи
Интересная статья о том, насколько различен подход к 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
➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи
- 👍 4
- ⚡ 2
- 🔥 2
