Книга «Грокаем Continuous Delivery»
Привет, Хаброжители!
Код должен быть готов к релизу всегда!
Пайплайн Continuous Delivery автоматизирует процессы контроля версий, тестирования и развертывания при минимальном вмешательстве разработчика. Освойте инструменты и методы непрерывной доставки, и вы сможете быстро и последовательно добавлять функции и выпускать обновления.
«Грокаем Continuous Delivery» — это руководство по настройке и работе с пайплайном непрерывной доставки. В каждой главе рассматривается отдельный сценарий, с которым вы столкнетесь при создании системы CD, и приводятся реальные примеры, например автоматическое масштабирование и тестирование унаследованных приложений. Кристи Уилсон сопровождает каждый шаг иллюстрациями, кристально четкими объяснениями и практическими упражнениями для закрепления полученных знаний.
Книга «Грокаем Continuous Delivery» предназначена для всех, кто день ото дня занимается созданием программного обеспечения. Чтобы польза от книги была максимальной, вы должны быть знакомы с основами написания shell-скриптов, владеть хотя бы одним языком программирования и иметь опыт тестирования. Вам также понадобится опыт работы с системой контроля версий, HTTP-серверами и контейнерами. Однако глубоко разбираться во всех этих темах не обязательно; вы сможете изучить их по ходу чтения, если понадобится.
- В главе 1 дается определение непрерывной доставки и объясняется ее связь со смежными понятиями, такими как непрерывная интеграция и непрерывное развертывание.
- В главе 2 перечислены основные элементы автоматизации непрерывной доставки, а также дана терминология, используемая в остальных частях книги.
- Глава 3 поясняет жизненно важную роль системы контроля версий в процессе непрерывной доставки; без этой системы непрерывная доставка невозможна.
- В главе 4 рассматривается эффективный, но редко обсуждаемый элемент непрерывной интеграции: статический анализ, в частности линтинг, и то, как его применять к унаследованному коду.
- Главы 5 и 6 посвящены тестированию — важнейшему элементу проверки в рамках непрерывной интеграции. Мы не будем учить вас тестировать (этому посвящено множество других книг), а сосредоточимся на самых частых проблемах, которые со временем накапливаются в наборах тестов, в частности на нестабильных и медленных тестах.
- В главе 7 рассматривается жизненный цикл изменений кода и исследуются все места, где могут возникнуть баги, а также способы настройки автоматизации для обнаружения и устранения этих багов по мере их появления.
- В главе 8 через призму метрик DORA рассматривается, как использование системы контроля версий влияет на скорость выпуска релизов.
- В главе 9 продемонстрировано, как создавать артефакты безопасно, применяя принципы, определенные стандартом SLSA, и объясняется важность версионирования.
- В главе 10 мы возвращаемся к метрикам DORA, основное внимание уделяя метрикам стабильности, и рассматриваем методы развертывания, которые можно использовать для повышения стабильности продукта.
- В главе 11 мы вернемся к элементам непрерывной доставки, которые изучались в предыдущих главах, и рассмотрим, как эффективно применять эти элементы в проектах, реализуемых с нуля, и в унаследованных проектах.
- В главе 12 основное внимание уделено «рабочей лошадке», часто лежащей в основе любой автоматизации непрерывной доставки: shell-скриптам. Вы увидите, как применять к скриптам, обеспечивающим безопасную и корректную доставку продукта, те же лучшие практики, что и к остальной части кода.
- В главе 13 представлена общая структура автоматизированных пайплайнов, которые необходимы для поддержки непрерывной доставки, и моделируются функции систем автоматизации непрерывной доставки, обеспечивающие их эффективность.
Я рекомендую начать с чтения главы 1; такие термины, как непрерывная доставка, в реальной жизни используются непоследовательно, и понимание их контекста для настоящей книги поможет вам лучше разобраться в остальных главах.
Удобнее всего осваивать материал, читая части 2 и 3 по порядку, поскольку все последующие главы основываются одна на другой. В частности, предполагается, что при переходе к части 3 вам известны практики непрерывной интеграции, описанные в части 2. Тем не менее вы можете изучать главы по своему усмотрению, так как в каждой главе вы найдете ссылки на соответствующий материал других глав.
Часть 4 — это продвинутый раздел книги. Каждая глава в ней ссылается на концепции, рассмотренные ранее, а некоторые материалы (например, глава 12) полезнее будет изучить, уже приобретя некоторый опыт работы с системами непрерывной доставки.
Скользящие обновления
Первая проблема, за которую принимаются Сарита и Арчи, заключается в том, что на исправление багов в продакшене уходит от нескольких часов до нескольких дней. Чтобы найти решение, они подробно изучают, как именно происходит развертывание обновлений на трех экземплярах вебсервера Plenty of Woofs.
При тщательном анализе становится ясно, что команда Plenty of Woofs использует скользящее обновление экземпляров веб-сервера. По очереди на каждом хосте останавливается текущий контейнер веб-сервера и запускается новый экземпляр (с новой версией). После обновления одного хоста обновляется следующий, и так далее, пока не будут обновлены все.
Cловарик
Скользящее обновление (rolling update) означает, что экземпляры обновляются до новой версии по очереди. В любой момент времени хотя бы один экземпляр сервиса запущен и работает, что позволяет избежать простоя всего сервиса. Более простой способ — снести все экземпляры и обновить их одновременно, но в таком случае сервис не будет работать, пока происходит обновление. Во время скользящего обновления часть пользователей подключается к более новым экземплярам сервиса, а часть — к старым (в зависимости от того, как направляются запросы к этим экземплярам).
Исправление багов при скользящем обновлении
Если обнаруживается баг, команда Plenty of Woofs осуществляет поиск исправления, а затем выпускает новый релиз, содержащий это исправление, по-прежнему используя скользящее обновление:
И конечно, скользящее обновление для исправления багов запускается только после того, как баг обнаружен и исправлен и новая версия веб-сервера собрана. Таким образом, общее время устранения сбоя в работе сайта Plenty of Woofs составляет:
(Время на исправление бага) + (Время на создание нового релиза) + 3 × (Время на обновление экземпляра)
Откаты
Если посмотреть на то, как происходит развертывание и куда уходит время, станет очевидно, что большая часть времени тратится на ожидание нового релиза:
Сарита и Арчи поняли, что когда развертывание приводит к сбою, не нужно оставлять сервис в неработающем состоянии и ждать исправления. Вместо этого можно сразу откатиться к предыдущей версии, которая, как известно, работает.
Поэтому если они производят развертывание версии 1.4.0 и оно завершается сбоем, вместо того, чтобы ждать версии 1.4.1 (то есть исправленной), можно вернуться к предыдущей версии (1.3.2). Как только ошибка будет исправлена и версия 1.4.1 станет доступна, сервис можно будет обновить с версии 1.3.2 до версии 1.4.1.
Откат = немедленное улучшение
Если команда Plenty of Woofs начнет применять стратегию отката при возникновении сбоев, время восстановления работоспособности сервиса резко сократится и будет равно времени, необходимому для отката до предыдущей версии при скользящем обновлении:
Время восстановления сокращается с нескольких дней до нескольких минут. Это сразу улучшает показатели DORA. Время на восстановление работоспособности сервиса уменьшится с нескольких дней или более до нескольких минут.
Сарита и Арчи немедленно сообщают о своем открытии остальным сотрудникам, и Plenty of Woofs вводит политику немедленного отката при возникновении сбоев. Это означает, что основной баг остается в коде и должен быть исправлен, но теперь это можно сделать спокойно в рабочее время, а не впопыхах, когда нужно как можно быстрее исправить рабочую версию.
Cловарик
Чтобы эффективно использовать откаты, нужна стратегия. Стратегия отката — это автоматизированный, задокументированный и протестированный процесс, указывающий, как выполнять откат. К этому процессу следует относиться так же серьезно, как к любому другому процессу разработки или развертывания, если не более, потому что откат будет происходить в наиболее чувствительное для сервиса время (когда он неисправен и создает проблемы у всех пользователей). Автоматизация и сопутствующие тесты (и даже «пожарные учения» для отработки отката) позволят проводить процесс гладко в самых критических случаях.
А что насчет отката данных?Когда развертывание включает изменения данных, откат становится немного сложнее. И что вполне естественно, большинство сервисов в той или иной форме содержат данные, схему взаимодействия с которыми необходимо обновлять по мере добавления новых функций и исправления багов.
К счастью, эта проблема решаема и не помешает использовать откаты. Чтобы обеспечить безопасное обновление (то есть развертывание) и откат по мере необходимости, потребуется внедрить несколько политик и рекомендаций в процесс:
Основная цель внедрения этих политик — осуществлять развертывание и откат изменений данных таким же образом, как для программ: проводить развертывание, когда требуется обновление, а если что-то пойдет не так, откатить все назад.
- Версионирование схем данных — подобно тому, как в предыдущей главе мы рекомендовали управлять версиями продукта (и семантическое версионирование здесь тоже может пригодиться), каждое изменение схемы базы данных должно сопровождаться соответствующим изменением версии.
- Создание скриптов обновления и отката для каждого перехода на новую версию — каждое изменение схемы базы данных должно сопровождаться двумя скриптами (или другими средствами автоматизации): одним — для перехода от предыдущей версии к новой и вторым — для отката с новой версии к предыдущей. Если вы создаете их для каждого изменения версии, вы сможете легко откатиться назад, насколько это необходимо, применяя скрипты по очереди при откате назад или для перехода на более позднюю версию.
- Обновление данных и сервисов по отдельности — если объединять обновление данных и сервисов и выполнять их одновременно, откат назад станет проблематичнее и чаще будет приводить к ошибкам. Выполняйте обновление по отдельности. Когда вы вносите изменения, сервисы должны без ошибок обрабатывать как старые, так и новые версии данных. Добиться этого непросто, но это стоит сделать, чтобы упростить процесс и понизить риски.
Аналогично, когда изменения функциональности требуют соответствующих изменений в структуре данных, можно обновить БД, добавив необходимые изменения. Опять же, постарайтесь не вносить эти изменения одновременно, чтобы откаты выполнялись независимо друг от друга.
В этой книге мы не будем подробно говорить о том, как работать с данными; чтобы узнать больше по этой теме, обратитесь к источникам, посвященным эффективному управлению данными.
Политика откатов в действии
Новая политика немедленного отката при возникновении сбоев (чтобы не ждать, пока команда создаст исправление) уже сэкономила Plenty of Woofs немало времени — и нервов! По мере внедрения этой политики Сарита и Арчи собирают данные и повторно анализируют метрику DORA «время восстановления работоспособности сервиса», чтобы подтвердить свою теорию о том, что это время сократится до минут и они попадут в категорию суперэффективных компаний. Изучая, что на самом деле происходит во время сбоя, они обнаружили, что общее время с момента начала сбоя до момента восстановления сервиса таково:
- Скользящее обновление трех экземпляров занимает 5–15 минут как при переходе к следующей версии (развертывание/обновление), так и при переходе к предыдущей (откат).
- Сбои возникают в начале скользящего обновления (после обновления первого экземпляра любой трафик, попадающий на этот экземпляр, начнет вызывать сбои).
- Для обнаружения сбоя требуется не менее 3 минут, а иногда и 10 минут.
- Как только становится ясно, что произошел сбой, инициируется откат. Сам откат представляет собой скользящее обновление всех трех экземпляров, и для его завершения потребуется еще 5–15 минут.
Таким образом, общее время от начала сбоя до решения проблемы составляет:
Таким образом, общее время от начала сбоя до его устранения составляет от 13 (5 + 3 + 5) до 40 (15 + 10 + 15) минут. Это означает, что метрика DORA «Время восстановления работоспособности сервиса» находится в интервале от 13 до 40 минут. Время на восстановление в 40 минут позволяет отнести компанию Plenty of Woofs к категории суперэффективных:
Сине-зеленые развертывания
Хотя метрика времени восстановления работоспособности значительно улучшилась, 40 минут потенциально означают 40 минут ошибок на стороне пользователя, а между максимальным значением в 40 минут и верхним пределом в 1 час не такая большая разница. Если что-то в процессе замедлится (например, если добавить еще несколько экземпляров сервера), то команда снова станет просто высокоэффективной. Сарита предлагает сосредоточиться на самом времени выполнения скользящих обновлений и посмотреть, можно ли что-то улучшить:
Сам процесс скользящего обновления добавляет от 6 до 20 минут ко времени простоя. Одним из способов сократить его является использование сине-зеленого развертывания вместо скользящего обновления. При сине-зеленом развертывании (также называемом красно-черным развертыванием) вместо обновления одного набора экземпляров по месту его размещения создается абсолютно новый набор экземпляров, который и обновляется. Только после того, как эти экземпляры будут готовы, трафик переключается с оригинальных экземпляров («синих», хотя на самом деле цвет значения не имеет) на новые («зеленые»).
Если с новыми экземплярами возникнут проблемы или произойдет сбой, то исправный набор экземпляров предыдущей версии будет продолжать работать. Откатиться назад будет так же просто, как переключить трафик на исходный набор экземпляров!
Она часто выступает с докладами по непрерывной интеграции и непрерывной доставке (CI/CD) и смежным тематикам на таких конференциях, как Kubecon, OSCON, QCon, PyCon и многих других. Кристи начала карьерный путь с разработки мобильных веб-приложений, работая над бэкенд-сервисами для ААА-игр, где она писала отложенные функции, которые начинали использоваться все вместе во время большого запуска. Для этого она создала системы нагрузочного и системного тестирования.
Имея опыт, полученный в компаниях, которые работали со сложными средами развертывания, системами с высоким уровнем критичности и скачкообразным трафиком, она перешла на работу в Google, где создавала внутренние инструменты для повышения производительности AppEngine, запустила Knative и участвовала в создании Tekton, облачной платформы CI/CD на основе Kubernetes (в настоящее время ее используют более 65 компаний).
Более подробно с книгой можно ознакомиться на сайте издательства:
» Оглавление
» Отрывок
По факту оплаты бумажной версии книги на e-mail высылается электронная книга.
Для Хаброжителей скидка 25% по купону — Continuous Delivery
