Непрерывная интеграция, доставка и развертывание
Занимаясь разработкой, вы наверняка сталкивались с понятиями непрерывной интеграции, доставки и развертывания (или CI/CD).
Это технологии, позволяющие ускорить процесс выпуска ПО за счет более коротких циклов обратной связи и автоматизации рутинных задач. Они играют ключевую роль в реализации принципа Agile о важности частого выпуска работающего ПО.
Для команд, которые выработали свой ритм и определились с набором CI/CD-инструментов и процессов для поддержания регулярного цикла релизов, хорошо работающий CI/CD-пайплайн — большая гордость. Также его наличие говорит о том, что разработчики действительно используют свои инструменты для улучшения условий разработки и создаваемого продукта.
Тем, кто совсем недавно познакомился с CI/CD, может показаться, что перестройка процессов сборки, тестирования и развертывания — это слишком сложно и нереалистично. Совсем не обязательно. Прелесть процедуры построения CI/CD-пайплайна в том, что она прекрасно разбивается на отдельные этапы, каждый из которых строится на основе предыдущего. Рассмотрим каждый из этих этапов.
Давайте разберемся, что такое CI и CD и в чем заключаются особенности каждого из этих процессов.
Что такое непрерывная интеграция?
Непрерывная интеграция подразумевает выполнение традиционных шагов по интеграции прямо в ходе процесса разработки — не дожидаясь завершения работы над кодом, сбора всей системы воедино и тестирования.
Предположим, что над разработкой вашего продукта работает больше одного человека — это типично для большинства коммерческого ПО и проектов с открытым исходным кодом. В какой-то момент вы захотите собрать по кусочкам все, над чем трудились ваши разработчики, и проверить, что конечный результат соответствует ожиданиям. Непрерывная интеграция предполагает, что это происходит раз в день, а то и чаще.
И ясно почему. Если вы отложите интеграцию до момента готовности кода, то, чтобы собрать решение (и тем более — достичь желаемой работоспособности), вам скорей всего придется долго раскраивать и переписывать различные фрагменты кода. Код — вещь сложная. Даже если он тщательно продуман заранее, вы едва ли будете знать наверняка, как выстроится логическое взаимодействие и будут ли ошибки. Чем больше кода, тем выше сложность и тем больше всего приходится раскраивать, когда что-то не работает.
С непрерывной интеграцией разработчики регулярно публикуют свои изменения, делая коммиты в систему контроля версий хотя бы раз в день, и проверяют, что сборка с их изменениями проходит все тесты. В таком случае, если что-то сломается, для нахождения проблемы вам нужно будет проанализировать небольшое количество изменений. Быстрое получение результатов также означает, что вам будет легче вносить исправления: контекст задачи будет по-прежнему свеж в голове.
Чтобы построить хороший CI-процесс, вам потребуется несколько ингредиентов:
Используйте контроль версий
Использование системы контроля версий абсолютно необходимо. Если вы не пользуетесь такой системой или же пользуетесь, но храните в ней только часть вашего кода, первым делом стоит перенести в нее весь код и приучить к ней ваших разработчиков.
Делайте коммиты рано и часто
Наладив работу с системой контроля версий, приучите всех делать коммиты изменений как можно раньше и чаще. Очень важен объем задачи: разбиение на части позволяет работать с небольшими порциями изменений и тестировать их локально, после чего можно делать коммит.
Выполняйте сборку при каждом коммите
Регулярная публикация изменений, чтобы их видели ваши коллеги по проекту, — это только начало. Следующим шагом нужно проверить, собирается ли решение, включающее эти изменения. Это можно делать и вручную. Однако гораздо проще и эффективнее запускать такие сборки автоматически, и для этого нам нужен CI-сервер.
Автоматизируйте тесты
Успешная сборка — хороший индикатор, однако для большей уверенности нужны тесты. Как мы уже говорили, проще и эффективнее выполнять не ручные, а автоматизированные тесты. И хотя написание автоматизированных тестов кажется трудоемким занятием, возможность впоследствии запускать их для каждой сборки и быстро получать результаты действительно стоит того.
Получайте обратную связь
Автоматизировать сборки и тесты имеет смысл, только если вы планируете как-то использовать получаемую информацию. Инструменты для CI предлагают целый ряд механизмов для обработки результатов, от панелей мониторинга и радиаторов до интеграции с платформами мгновенного обмена сообщениями.
Создайте DevOps-культуру
Чтобы получить максимум пользы от непрерывной интеграции, вам нужно создать такую культуру в команде, где каждый готов взять на себя ответственность за исправление упавшей сборки или теста. Обвинять того, чей коммит был последним, — непродуктивный подход: зачастую он отбивает у разработчиков желание делать ранние коммиты, даже если это против общих интересов команды.
Перечисленные нами ингредиенты CI обеспечат вам быструю и регулярную обратную связь по вашему коду. Запуская сборку и тесты для каждого изменения, будь то исправление ошибки, рефакторинг или новая функциональность, команда избежит ситуации, когда необходимо переделывать неудачный код, поверх которого уже создана новая функциональность. Реализация непрерывной интеграции — это большой шаг на пути к ускорению процесса выпуска работающих приложений.
О непрерывной доставке
Непрерывная доставка основывается на автоматизации сборки и тестирования, которую вводит непрерывная интеграция.
Она предполагает перевод ручных шагов, необходимых для выпуска сборки приложения в продакшн, — в автоматизированный процесс.
Раньше работа могла передаваться от разработчиков тестировщикам, а затем релиз-менеджерам. Внедряя непрерывную доставку, ваша команда (включающая самых разных специалистов) начинает полностью управлять процессами сборки, тестирования и релиза своего продукта. У такого подхода есть ряд преимуществ:
- Избегая традиционной разобщенности, ваша команда будет лучше понимать бизнес-потребности и операционные нужды, возникающие при доставке продукта пользователям.
- Это в свою очередь позволяет привнести некоторые практики разработки в процесс, который принято считать ручным и довольно длительным.
- Применение автоматизации не только ускоряет процесс доставки, но и снижает вероятность возникновения ошибок, делая его более стабильным и надежным.
То, из каких шагов состоит процедура доставки приложения и каких стадий пайплайна они требуют, зависит от нужд вашего бизнеса и пользователей. Распространенной практикой является развертывание приложения хотя бы в одном препродакшн-окружении перед окончательным выпуском.
Это может быть тестовое окружение, предназначенное для дополнительных видов тестирования (безопасности, производительности, нагрузки); это могут быть песочницы (изолированные среды), с помощью которых команды поддержки и продаж знакомятся с новой функциональностью; также это могут быть окружения для приемочного тестирования, где QA-команда и специалисты по продукту проверяют ПО на соответствие требованиям.
Непрерывная доставка предполагает, что для каждой успешной сборки автоматически выполняется развертывание на каждом препродакшн-окружении. Прохождение вашего ПО через каждое из них поможет закрепить уверенность в качестве продукта.
Чтобы реализовать это, вам нужно:
Выполняйте сборку однократно
Работая с одним и тем же артефактом на протяжении всех этапов пайплайна, вы сможете быть уверенными, что он прошел все предыдущие стадии тестирования.
Храните конфигурацию в VCS
Хранение всех конфигурационных файлов в системе контроля версий обеспечит консистентность и повторяемость процедуры развертывания.
Автоматизируйте развертывание
Развертывание в окружениях должно выполняться с помощью скрипта. Так вы сможете делать развертывание автоматически, а значит, будете уверенны, что оно каждый раз выполняется идентичным образом. По той же причине у вас должен быть скрипт и для релиза в продакшн, однако непрерывная доставка предполагает, что это шаг выполняется вручную.
Чистите ваши окружения
Чтобы соблюдать консистентность, перед каждым развертыванием необходимо сбрасывать настройки окружений до одного и того же исходного набора условий. Благодаря контейнерам теперь это реализуется намного проще (используется локальная инфраструктура или же облако).
Отделите параметры окружения
Чтобы автоматизировать развертывание одного и того же артефакта на каждом окружении, у вас должно быть четкое разделение между приложением и переменными или параметрами среды.
Поддерживайте пайплайн
Как и с непрерывной интеграцией, создавать автоматизированный пайплайн доставки стоит только в том случае, если вы готовы поддерживать его. CI/CD — это не только процессы и инструменты, но и культура команды. Чтобы быть эффективной, ваша команда должна взять на себя ответственность за поддержание пайплайна и решение любых возникающих проблем, будь то ошибка в коде или проблема с автоматизированным развертыванием и тестами.
Непрерывная доставка позволит вашей команде взять на себя ответственность за доставку ПО и получать своевременную обратную связь по процессу. Как и с непрерывной интеграцией, вы можете выстраивать и улучшать процесс постепенно.
О непрерывном развертывании
Непрерывное развертывание завершает логическую цепочку из практик непрерывной интеграции и доставки:
если сборка успешно проходит все предыдущие стадии пайплайна, она автоматически выпускается в продакшн. А значит, как только выполненные изменения проходят все тесты, — они становятся доступными для пользователя. Непрерывное развертывание ускоряет цикл обратной связи, начинающийся с изменений в коде и заканчивающийся поступлением их в продакшн, и дает команде возможность своевременно проверять, как их изменения поведут себя в реальном мире, не рискуя качеством.
Непрерывное развертывание подойдет не любому продукту и не любой организации. Однако имеет смысл рассмотреть шаги, которые оно включает, поскольку каждый из них способен нести ценность сам по себе:
Будьте уверены в своих тестах
Для автоматического развертывания в продакшне вы должны быть твердо уверенными в вашем пайплайне, в частности в автоматизированных тестах. Необходима культура тестирования, где команда инвестирует в тестовое покрытие и производительность, отдает более высокий приоритет исправлению проблем сборок и пайплайнов, а уж потом занимается разработкой новой функциональности.
Следите за продакшном
Даже при наличии вышеперечисленных мер непрерывное развертывание может казаться довольно рискованной практикой. Что если тестирование не выявит ошибку и она проявится в продакшне? Время, деньги, репутация — все это ставится на карту. Та же проблема может возникнуть и при ручном развертывании, однако ничто не подорвет уверенность ваших стейкхолдеров больше, чем шоустоппер, выпущенный некой системой автоматически. Решающую роль здесь играет то, занимаетесь ли вы активным поиском проблем или же просто ждете, пока вам поступят отчеты об ошибках. Мониторинг статистики на предмет любых отклонений от нормы (выполняемый, в частности, сразу после релиза) поможет выявить проблемы до того, как их заметит пользователь.
Выбирайте, что релизить
Новички часто возражают, что, если разработчики будут делать коммиты рано и часто и изменения не будут проверяться вручную, то пользователи будут получать недоделанную функциональность, которая еще не готова к использованию. Чтобы не упускать преимущества непрерывной интеграции, вместо веток вы можете использовать флаги функций. Так вы сможете контролировать, какие возможности видны пользователю, а какие скрыты, и спокойно продолжать разработку.
Оптимизируйте пайплайн
В случае если в продакшне что-то пойдет не так, хотелось бы иметь возможность действовать быстро. В некоторых случаях вы сможете откатиться к предыдущий версии. Однако зачастую вещи обстоят чуть сложнее. Миграции баз данных и исправления ошибок может быть сложно откатить, и тогда вам придется чинить проблему. Пропуск шагов пайплайна — экономия, но ложная, так как вы, скорей всего, пропустите другие проблемы, которые могли бы выявить тесты. Вместо этого лучше инвестировать в оптимизацию вашего пайплайна: в ускорение сборок, повышение производительности тестов и пр. Это позволит при необходимости быстрее делать развертывание изменений, а также ускорит циклы обратной связи для всего процесса.
Контролируйте выпуск
Непрерывное развертывание предполагает, что релиз происходит автоматически при условии, что все предыдущие этапы прошли проверку. Но это не значит, что у вас не будет контроля за происходящим. Есть различные технологии, позволяющие минимизировать риски и управлять выпуском. Canary-релизы дают возможность тестировать продукт на небольшой доле пользователей, а сине-зеленое развертывание позволяет управлять переходом на новую версию.
Непрерывная интеграция, доставка и развертывание служат одной цели — частому выпуску работающего ПО. Понемногу и часто — использование этого подхода для интеграции и релиза делает процесс более управляемым, а выполняя шаги регулярно, команды учатся делать это все лучше и лучше.
Применение автоматизации не только ускоряет процесс, но делает его более надежным. Каждый шаг пайплайна строится на основе предыдущего — вы можете выбирать для себя нужное количество шагов и надстраивать их при необходимости.
Основные различия между CI и CD
Непрерывная интеграция, доставка и развертывание — последовательные этапы процесса поставки программного обеспечения. Вместе они помогают командам ускорить выпуск ПО, сократить цикл обратной связи, автоматизировать повторяющиеся задачи и обеспечить надежный и стабильный процесс доставки ПО пользователям. В чем же их отличия?
Непрерывная интеграция — это практика слияния любых новых изменений кода с основной веткой. Непрерывная доставка автоматизирует ручные задачи, необходимые для сборки и тестирования ПО (например, путем автоматизации тестов). Непрерывное развертывание является логичным продолжением автоматизации сборки и тестирования: на этом этапе ПО развертывается автоматически, как только проходит все необходимые контрольные точки.
В общем, вопрос не в том, что лучше — CI или CD, а скорее в том, как с помощью этих компонентов, работающих вместе, создать стабильный и надежный пайплайн.