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

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

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

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

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

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

1. Этап компонентов
2. Этап подсистем
3. Этап систем
4. Этап рабочей среды

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробнее см. в нашем учебном руководстве по непрерывной поставке.