Закрыть

Знакомство с конвейером непрерывной поставки

Узнайте, как автоматизированные сборки, тесты и развертывания объединяются в единый процесс выпуска.

Что такое конвейер непрерывной поставки?

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

Работая в соответствии с потребностями бизнеса, конвейер CD часто и предсказуемо в автоматическом режиме поставляет качественный продукт из среды тестирования в промежуточную среду и затем в рабочую среду.

Для начала давайте сфокусируемся на трех понятиях: качество, периодичность и предсказуемость.

Качество стоит здесь на первом месте, чтобы подчеркнуть: мы не жертвуем им в пользу скорости. Конвейеры для скоростной отправки в рабочую среду некачественного кода никому не нужны. Ниже мы рассмотрим принципы «сдвига влево» и DevSecOps, а также объясним, каким образом можно сместить решение вопросов безопасности и обеспечение высокого качество кода на более ранние этапы цикла разработки программного обеспечения (SDLC). После этого конвейер непрерывной поставки уже не будет восприниматься как источник риска для бизнеса.

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

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

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

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

Статьи о конвейерах непрерывной поставки

[ПРОДОЛЖЕНИЕ]

Этапы конвейера непрерывной поставки

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

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

Даже если количество этапов предполагается увеличить или уменьшить, перечисленные ниже принципы все равно остаются в силе.

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

Стоимость исправления дефектов будет низкой при обнаружении дефекта в тестовой среде, средней — при обнаружении дефекта в промежуточной среде и высокой — при обнаружении дефекта уже в рабочей среде. Термином «сдвиг влево» обозначается выполнение проверок на более ранних этапах конвейера. Сегодня на переходе от среды тестирования к промежуточной среде используется гораздо больше встроенных защитных механизмов, чем в прошлом, поэтому современная промежуточная среда уже не должна напоминать место преступления.

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

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

CD: этап компонентов

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

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

Модульные тесты почти всегда являются первым набором программных тестов для проверки нашего кода. Они не затрагивают базу данных или сеть. Покрытие кода — это процент кода, который был охвачен модульными тестами. Есть много способов измерить покрытие: через покрытие строк, покрытие классов, покрытие методов и т. д.

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

Статический анализ кода позволяет выявить наличие в коде проблем без его запуска. Это экономичный способ выявления проблем. Как и модульные тесты, такие тесты выполняются на исходном коде и отличаются быстротой выполнения. Статические анализаторы выявляют потенциальные утечки памяти, а также индикаторы качества кода, такие как цикломатическая сложность и дублирование кода. На этом этапе SAST (тестирование безопасности со статическим анализом) — проверенный способ обнаружения уязвимостей безопасности.

Определите показатели, которые будут контролировать переход ПО между этапами и регламентировать продвижение кода от этапа компонентов к этапу подсистем.

Непрерывная поставка: этап подсистем

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

Пользовательский интерфейс Node.js и уровень API Java являются подсистемами, и базы данных точно так же представляют собой подсистемы. В некоторых организациях обслуживание систем управления реляционными базами данных (RDBMS) осуществляется вручную, хотя уже появилось новое поколение инструментов, которые автоматизируют управление изменениями базы данных и позволяют успешно выполнять непрерывную поставку баз данных. Конвейеры непрерывной поставки, включающие базы данных NoSQL, проще в реализации, чем RDBMS.

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

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

Определите показатели производительности совместно с владельцами продукта. Интегрируйте свои тесты производительности в конвейер и определите условия прохождения и остановки конвейеров на основе этих показателей. Распространено заблуждение, что тесты производительности не должны интегрироваться с конвейерами непрерывной поставки, однако это противоречит принципу непрерывности.

В последнее время участились взломы крупных организаций, а угрозы кибербезопасности стали острее, чем когда-либо. И здесь важно засучить рукава и убедиться, что в наших продуктах угрозы безопасности отсутствуют — как в коде, который мы пишем, так и в сторонних библиотеках, которые мы импортируем в код. На практике серьезные нарушения требований безопасности обнаруживаются и в ПО с открытым исходным кодом (OSS), поэтому необходимо использовать инструменты и методы, которые выявляют такие ошибки и заставляют конвейер прерывать работу. DAST (тестирование безопасности с динамическим анализом) — проверенный способ обнаружения уязвимостей безопасности.

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

А) Сертификация компонентов и/или подсистем в тестовой среде

Непрерывная поставка: этап систем

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

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

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

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

Конвейер может автоматически подавать запросы на изменение (CR) для сохранения истории аудита. В большинстве организаций этот процесс используется для стандартных изменений, то есть запланированных релизов. Этот же процесс следует использовать и для экстренных изменений (то есть незапланированных релизов), хотя некоторые команды предпочитают в таких ситуациях «срезать углы». Обратите внимание, что запрос на изменение (CR) автоматически закрывается конвейером CD в случае вынужденного прерывания его работы из-за ошибок. Это предотвращает ситуацию, когда выполнение запросов CR прекращается посреди процесса конвейера.

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

Б) Сертификация подсистем и/или системы в промежуточной среде

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

Непрерывная поставка: этап рабочей среды

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

ZDD (развертывание без простоев) является обязательным условием для непрерывной работы клиентов, и его следует практиковать на всем пути от среды тестирования до промежуточной и рабочей сред. Сплит-развертывание является популярным методом ZDD, в котором новые элементы развертываются в крошечном сегменте клиентской базы (называемом «зеленым» сегментом), в то время как большая часть клиентов в счастливом неведении остается в «синем» сегменте, содержащем старые элементы. Если возникнет сбой, можно вернуть всех обратно в «синий» сегмент, и это затронет очень малую часть клиентов, если вообще кого-либо затронет. Если в «зеленом» сегменте все идет хорошо, можно постепенно перевести всех из «синего» в «зеленый» сегмент.

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

Однако я заметил, что в некоторых организациях злоупотребляют ручными проверками. Там начинают требовать, чтобы команды получали ручное одобрение на заседании CAB (собрания по одобрению изменений). Причиной этого чаще всего является неправильное толкование разделения обязанностей или разделения интересов: один отдел передает вопрос другому, ожидая одобрения для продвижения вперед. Я также замечал, что некоторые утверждающие участники CAB демонстрируют поверхностное техническое понимание изменений, направляемых в рабочую среду, что делает процесс утверждения вручную медленным и неповоротливым.

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

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

Следующая схема иллюстрирует шаги, выполненные командой на этом заключительном этапе непрерывной поставки.

В) Сертификация подсистем и/или системы в рабочей среде

Непрерывная поставка уже стала нормой

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

Конвейер непрерывной поставки помогает вам превращать идеи в продукты, проводя серии устойчивых экспериментов. Если вы обнаружите, что какая-то идея не оправдала ожиданий, вы можете быстро вернуться к делу с идеей получше. Кроме того, конвейеры сокращают MTTR (среднее время устранения) проблем в рабочей среде и, следовательно, время простоя приложения для клиентов. Благодаря непрерывной поставке вы получаете продуктивные команды и довольных клиентов. Кто же этого не хочет?

Джуни Мукхерджи
Джуни Мукхерджи

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