Джин Ким - Руководство по DevOps

Рис. 13. Конвейер развертывания (источник: Humble and Farley, Continuous Delivery, 3)

Конвейер развертывания, впервые описанный Джезом Хамблом и Дэвидом Фарли в их книге Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation, гарантирует, что весь код, записанный в систему контроля версий, автоматически собран и проверен в среде, близкой к производственной. Действуя таким образом, мы обнаруживаем любые ошибки сборки, тестирования или интеграции сразу же, как только они появились, что позволяет нам немедленно их исправить. При правильном выполнении процедур мы можем всегда быть уверенными, что код находится в состоянии готовности к развертыванию и релизу.

Для достижения этой цели необходимо создать автоматизированные процессы сборки и тестирования, выполняющиеся в выделенных средах. Это имеет жизненно важное значение по следующим причинам:

• процессы сборки и тестирования можно запустить в любое время и независимо от того, какой стиль работы предпочитают другие инженеры;

• раздельные процессы сборки и тестирования гарантируют, что мы понимаем все зависимости, необходимые для сборки, упаковки, запуска и тестирования нашего кода (то есть проблема «это работало на ноутбуке разработчика, но не работает в производственной среде» исключена);

• мы можем упаковать наши приложения, чтобы обеспечить повторяемость установки кода и конфигураций в разных средах (например, в Linux RPM, yum, npm, в Windows, OneGet, могут также использоваться альтернативные системы упаковки для интегрированных систем, такие как файлы EAR и WAR для Java, gems для Ruby и так далее);

• вместо того чтобы упаковывать наш код, мы можем помещать наши приложения в развертываемые контейнеры (например, Docker, Rkt, LXD, AMIs);

• среды могут быть сделаны более близкими к производственным, причем стабильным и повторяемым способом (например, из среды удаляются компиляторы, выключаются флаги отладки и тому подобное).

Конвейер развертывания после любого изменения проверяет, что код успешно интегрируется в среду, близкую к производственной. Он становится платформой. Через нее тестировщики запрашивают сборки и сертифицируют их во время приемочных испытаний и тестирования удобства использования, и он будет автоматически выполнять проверки производительности и безопасности.

Кроме того, он будет использоваться для самообслуживающихся сборок сред приемо-сдаточного тестирования, интеграционного тестирования и тестирования безопасности. На следующих шагах, по мере того как мы станем развивать конвейер развертывания, он также будет использоваться для управления всеми видами деятельности, необходимыми, чтобы провести сделанные изменения от системы контроля версий до развертывания.

Для обеспечения функциональности конвейера развертывания были разработаны различные продукты, в том числе с открытым исходным кодом (например, Jenkins, ThoughtWorks Go, Concourse, Bamboo, Microsoft Team Foundation Server, TeamCity, Gitlab CI, а также решения на базе облачных служб, таких как Travis CI and Snap) [76].

Мы начнем создавать конвейер развертывания с той стадии записи изменений кода, когда делается сборка и создается установочный пакет, запускаются автоматизированные модульные тесты и выполняются дополнительные проверки, такие как статический анализ кода, анализ на дублирование кода, проверка тестового покрытия и проверка стилей [77]. В случае успеха запускается стадия приемки: автоматически развертываются пакеты, созданные на этапе записи изменений, и запускаются автоматизированные приемочные тесты.

После того как изменения будут включены в систему контроля версий, желательно, чтобы упаковка кода делалась только один раз, с тем чтобы для развертывания кода по всей протяженности конвейера развертывания использовались те же самые пакеты. При этом код будет развертываться для интеграционного тестирования в тестовых средах точно так же, как и в производственной среде. Это уменьшает возможные отклонения, что позволяет избежать трудно диагностируемых ошибок на выходе процесса (например, с использованием разных компиляторов, флагов компиляции, разных версий библиотек или конфигураций) [78].

Цель конвейера развертывания — предоставление каждому включенному в поток создания ценности, особенно разработчикам, как можно более быстрой обратной связи о том, что внесенные изменения нарушают готовность продукта к развертыванию. Это может быть изменение, внесенное в код, в любую из наших сред, в автоматизированные тесты или даже в инфраструктуру конвейера развертывания (например, настройки конфигурации Jenkins).

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

Эта информация также помогает нам выполнить требования аудита и соответствия нормам и правилам, поскольку соответствующие подтверждения автоматически создаются в ходе повседневной работы.

Теперь, когда у нас есть работающая инфраструктура конвейера развертывания, мы должны создать методы непрерывной интеграции, обеспечивающие следующую функциональность:

• всеобъемлющий и надежный комплекс автоматизированных проверок, подтверждающий, что мы готовы к развертыванию;

• производственную культуру, «останавливающую всю производственную линию», когда тесты сообщают о сбое;

• разработчики трудятся над небольшими пакетами изменений основной ветви кода, а не над отдельной долгоживущей веткой для выделенного функционала.

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

На предыдущем шаге мы начали создавать инфраструктуру автоматизированного тестирования, проверяющую наличие зеленой сборки (такой, где все компоненты в системе контроля версий находятся в состоянии, обеспечивающем сборку и развертывание). Чтобы подчеркнуть, почему нам необходимо выполнять этот шаг — интеграции и тестирования — непрерывно, рассмотрим, что происходит, когда мы выполняем эту операцию лишь периодически, например в ходе ночных сборок.

Предположим, у нас есть команда из десяти разработчиков, и каждый ежедневно записывает изменения кода в системе контроля версий. Один вносит изменение, «ломающее» выполнение ночной сборки и работу по ее тестированию. В этом сценарии мы, придя утром на работу, обнаружим отсутствие «зеленой сборки», и потребуется несколько минут или, что более вероятно, несколько часов, пока команда выяснит, какие именно изменения вызвали проблему, кто их внес и как это исправить.