How Amazon and Google view CI/CD in an entirely different way (Рубрика Architecture)

Очень интересная статья про разные подходы двух крупных компаний к построению своих процессов CI/CD. Автор проработал суммарно 15 лет в инженерных командах, что занимались CI/CD инфраструктурой: сначала 11 лет в Amazon, потом 4 года в Google, а потом вернулся обратно в Amazon. И в этой статье он рассказывает, как отличчается школа мысли этих двух компаний к построению своих процессов CI/CD, фокусируясь на следующем трио - Pre-submit - эта фаза относится к developer experience до сабмита кода. Собственно, автор разбирает то, какие проверки можно вкрутить на этом этапе в своем рабочем пространстве или как часть процесса code review

• Post-submit - это фаза относится к developer experience после сабмита кода. Как происходит merge изменений, как код развертывается в prod-like тестовых средах и прогоняются проверки там, и как код дальше выкатывается на прод
• Testing - автор в статье говорит про интеграционное и сквозное тестирования, а не модульное. Модульное тестирование тривиально для запуска в любом месте, но интеграционное тестирование требует, чтобы код-кандидат был развернут в тестируемой системе и связан с зависимостями, что добавляет экспоненциальный уровень сложности к инфраструктуре.

Дальше он говорит, что Google и Amazon по разному хостят свой код

• Google использует monorepo и весь код хранится в одном месте
• Amazon использует концепцию microrepos, где код отдельных сервисов хранится в отдельных репозиториях

И это отличие обуславливает разный подход к инструментам и фокусировке на разных этапах developer experience.

Если кратко, то Google крут в pre-submit проверках, так как сотни тысяч инженеров живут в общем репозитории, где нет отдельных бранчей. Blast radius при сабмите проблемного кода очень велик, поэтому они очень много инвестируют в разные крутые штуки на pre-submit (вот другая статья автора, где он рассказывает про это run end-to-end integration tests from a local dev environment, or a code review, against ephemeral, hermetic test environments). Но вот post-submit опыт совсем другой - код катится на прод совсем не часто. Суть здесь в том, что изменения разных инженеров накапливаются в батчи, по которым прогоняется большее количество тестов. Это сделано потому, что одна строчка кода может повлиять на большое количество deployments, поэтому запускать все проверки на каждый коммит точно не получится. Но расплата за это - долгое ожидание доставки кода на продакшен.

В Amazon код живет микрорепах, где blast-radius изменений ограничен твоим репо (по крайней мере, на pre-submit части). То есть, закоммитив что-то странное, ты легко навредишь только своим коллегам по 2-pizza-team. А дальше включаться post-submit проверки, которые не позволят раскатиться этому изменению. Поэтому в Amazon слабая автоматизация pre-submit части, но вот post-submit сделан сильно лучше, чем в Google. Отличие в том, что изменения в коде оказываются на проде в течение часов, а не суток.

Финализируя, автор говорит, что Google и Amazon выбрали разные подходы для борьбы со сложностью

• Monorepo ребят из Google работает за счет большой команды, что автоматизирует pre-submit и делает умную селективность тестов, позволяет им запускаться герметично и так далее, но код доставляется на прод долго. Но если требуются крупные изменения по кодовой базе, то их легче сделать в одной монорепе
• Microrepos ребят из Amazon проще менять и выкатывать новый фичевый код на прод, не опасаясь больших проблем. Но вот проблемы с обновлением зависимостей в разных репозиториях - это боль. В итоге, автор статьи отмечает, что поддерживать подход Amazon можно гораздо меньшей командой И тот и другой подход имеет право на жизнь и фактически задает некоторую школу мысли для своих адептов:) Автору больше нравится подход Amazon

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

#CI #SRE #Architecture #Software #Infra #QA