Непрерывная интеграция, доставка и развертывание (CI/CD)

Что такое непрерывная интеграция?

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

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

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

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

О непрерывной доставке:

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

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

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

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

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

О непрерывном развертывании:

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

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

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

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

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

• Следите за продакшном. Даже при наличии вышеперечисленных мер непрерывное развертывание может казаться довольно рискованной практикой. Что если тестирование не выявит ошибку и она проявится в продакшне? Время, деньги, репутация — все это ставится на карту. Та же проблема может возникнуть и при ручном развертывании, однако ничто не подорвет уверенность ваших стейкхолдеров больше, чем шоустоппер, выпущенный некой системой автоматически. Решающую роль здесь играет то, занимаетесь ли вы активным поиском проблем или же просто ждете, пока вам поступят отчеты об ошибках. Мониторинг статистики на предмет любых отклонений от нормы (выполняемый, в частности, сразу после релиза) поможет выявить проблемы до того, как их заметит пользователь.

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

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

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

License

Copyright 2022-present Борис Тараканов.

Released under the MIT license.