Важность непрерывной интеграции (Continuous integration, CI) ПО для современного предприятия подчеркивалась неоднократно. Независимый консультант в области инженерии ПО Руан Вильсенах рассказывает на портале TechBeacon о трех этапах, которые нужны для развертывания программных изменений в производственную среду.

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

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

1. Настройка сборочного сервера

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

Если вы используете хостинговую службу управления версиями, такую как GitHub или GitLab, то CI-предложение уже включено в ваш пакет. Если использование облачного CI-сервера не является опцией, установите Jenkins — этот инструмент бесплатный и работает на базе Open Source.

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

Начинать нужно с простого — скомпилируйте или упакуйте приложение. Подумайте о том, что потребуется для передачи кода в производство и в обратном направлении. Может быть, вам нужно создать образ Docker или связать JavaScript с wepback. Цель состоит в том, чтобы в процессе сборки можно было последовательно создавать артефакты, которые необходимо развернуть в производстве.

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

2. Настройка проверок

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

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

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

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

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

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

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

3. Добавьте шаг развертывания

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

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

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

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

Готовность к взлету

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