Конвейер CI/CD — это автоматизированный, повторяющийся метод разработки, доставки и развертывания, применяемый на протяжении всего жизненного цикла приложения — от решения о его создании до выведения из эксплуатации.
По логике аббревиатура должна выглядеть как CI/CD/CD — continuous integration (CI), continuous delivery (CD) и continuous deployment (CD). Однако получила распространение укороченная версия: CI/CD, в которой под CD понимается как continuous delivery (непрерывная доставка), так и continuous deployment (непрерывное развертывание).
Проще говоря, CI/CD — это метод разработки приложений, при котором изменения кода в центральном репозитории производятся непрерывно, после чего автоматически выполняется сборка, тестирование и развертывание. Это позволяет быстро доставлять изменения в среду продакшн и избавиться от так называемого “интеграционного ада” — так в классической модели называется многочасовой процесс интеграции кода, написанного разными разработчиками.
Что такое классическая модель жизненного цикла разработки
Классическая модель жизненного цикла разработки программного обеспечения (SDLC) выглядит следующим образом:
- идея,
- определение требований,
- архитектура системы,
- разработка,
- тестирование,
- развертывание,
- поддержка.
Эта модель используется многие годы и хорошо себя зарекомендовала. Однако с появлением и повсеместным использованием контейнерных приложений модель SDLC стала терять популярность. Причина этого — достаточно длительное время разработки, сравнительно со скоростью создания и развертывания контейнерных приложений. Это связано с тем, что в SDLC процесс исправления и интеграции кода редко проходит гладко.
Возможные проблемы с интеграцией кода при классическом методе разработки
При разработке приложений над исправлением ошибок или добавлением новых функций редко трудится одна команда разработчиков. Обычно сразу несколько команд работают над разными задачами. Каждая команда меняет существующий или добавляет новый код для решения своих задач. В ходе работы над общим проектом каждая команда разработчиков, принимающая участие в работе над проектом, меняет контекст для других команд разработчиков, ведь все команды работают над одним исходным кодом. Когда одна из команд завершает свои задачи, она копирует свой код в центральный репозиторий.
В этот момент может выясниться, что приложение, над которым работала эта команда, изменилось. Обновления в коде приложения могут вступить в конфликт с изменениями, внесенными командой. Например, изменились API-интерфейсы, на которые до этого полагалась команда. В таком случае разработчикам придется внимательно изучить изменения и внести исправления в код.
Проблемы с интеграцией кода могут возникнуть из-за влияния очень многих факторов. Разные версии фреймворков, библиотек, баз данных — все это потенциальные источники конфликтов при интеграции. Таким образом, объем работы, необходимый для написания кода и решения проблемы, изначально возложенной на разработчика, может резко увеличиться из-за проблем с интеграцией. Тестирование и исправление ошибок может потребовать дополнительного времени. Из-за этого релиз приложения может выйти позже, чем планировалось, да и циклы выпуска релизов могут стать трудно предсказуемыми по срокам.
При этом разработчикам важно выкатывать обновления как можно быстрее и желательно в автоматизированном режиме, что и предопределило успех модели CI/CD.
Метод CI/CD
Цикл разработки CI/CD короче, чем в традиционной модели. У него всего четыре стадии
- коммит
- сборка
- тестирование
- развертывание
Главная задача непрерывной интеграции (CI) — быстрое обнаружение и исправление ошибок, улучшение качества ПО и сокращение времени, затрачиваемого на проверку и релизы новых обновлений. Быстрота и легкость в обнаружение ошибок — одно из ключевых преимуществ непрерывной интеграции. Поскольку каждое внесенное изменение обычно невелико, можно быстро определить то конкретное изменение, которое вызвало дефект.
Благодаря работе небольшими итерациями, процесс разработки программного обеспечения становится предсказуемым и надежным. Разработчики постоянно создают новые функции и развертывают приложения в любой подходящий момент. Кроме того, при внесении изменений в основную кодовую базу они могут автоматически переводить ее в среду продакшн.
На практике весь процесс от написания кода до развертывания его в продакшене может занимать всего несколько минут.
Непрерывная интеграция (CI) и тестирование
Чтобы избежать проблем с интеграцией кода, присущих классическому методу, разработчики ежедневно или даже несколько раз в день интегрируют свою частично завершенную работу в центральный репозиторий. При этом они должны убедиться, что их код будет работать после интеграции в репозиторий. Единственный способ проверить это — протестировать каждую функцию приложения.
Тестирование — это ключевой элемент непрерывной интеграции. Однако ручные тесты занимают слишком много времени. Поэтому важнейшим условием для непрерывной интеграции является наличие автоматизированного набора тестов. Они снимают с разработчиков бремя ручного, затратного по времени и подверженного ошибкам процесса тестирования.
Разработка на основе тестирования — это метод, который помогает разработчикам писать чистый, поддерживаемый код одновременно с написанием тестов для него. Тестирование имеет смысл только в том случае, если оно выполняется всегда при каждом изменении исходного кода.
Результат непрерывной интеграции настолько важен, что у многих команд есть правило прекращать работу над своей текущей задачей, если версия в центральном репозитории не работает. Они присоединяются к команде, которая работает над исправлением кода, до успешного прохождения тестирования. Роль системы непрерывной интеграции заключается в улучшении взаимодействия между разработчиками путем передачи статуса исходного кода проекта
Непрерывная доставка (CD)
Непрерывной доставкой называются автоматизированные процессы доставки программного обеспечения в разные среды короткими контролируемыми циклами. Как только, изменение в коде фиксируется в центральном репозитории, оно собирается сервером сборки и затем тестируется. После прохождения тестов изменение кода отмечается как готовое к релизу. Такой подход гарантирует, что никакой новый релиз не станет причиной сбоя в работе приложения. Конечная цель непрерывной доставки — наличие кодовой базы, готовой к развертыванию в среде продакшн.
Непрерывное развертывание (CD)
Этап непрерывного развертывания отвечает за релиз изменений в среду продакшн. У разработчиков есть несколько способов сделать это.
Стратегии развертывания приложений в CI/CD
Платформа оркестрации контейнеров Kubernetes позволяет развертывать релизы в продакшене разными способами. Перечислим самые известные из них.
Сине-зеленое — одновременное развертывание старой и новой версии приложения (называемых синяя и зеленая). Ниже разберем его подробнее.
Canary — похоже на сине-зеленое, но отличается поэтапным подходом к развертыванию. Сначала обновление тестируется на небольшой группе пользователей, если все хорошо, то количество пользователей постепенно растет.
Rolling — постепенное развертывание, при котором новые наборы контейнеров (pod в Kubernetes) один за другим меняют наборы со старой версией приложения. В случае возникновения проблем развертывание обновления можно прервать.
Recreate — повторно создаваемое развертывание. Все наборы контейнеров с устаревшей версией одновременно заменяются на новые.
A/B — при таком развертывании новые функции доступны лишь части пользователей, которые даже не догадываются, что они становятся тестерами обновления.
Рассмотрим подробнее один из популярных вариантов развертывания — сине-зеленое.
Сине-зеленое развертывание
Сине-зеленое развертывание — это модель выпуска приложения, в которой пользовательский трафик из предыдущей версии приложения постепенно переносится в почти идентичный новый релиз, при том, что оба релиза работают в среде продакшн. Активным при этом является только один из них, например, синий. При подготовке новой версии, ее тестирование проводится в зеленом продакшене. После успешного тестирования зеленый продакшн становится активным, а синий переводится в режим ожидания, на случай отката, если что-то пойдет не так. Кроме того, синий продакшен может быть извлечен из среды продакшн, чтобы стать шаблоном, на основе которого будет выполнено следующее обновление.
Таким образом, зеленый и синий продакшен регулярно проходят через три состояния — действующее приложение, старая версия на случай отката и staging-среда следующей версии.
Инструменты для автоматизации процессов CI/CD
Существует достаточно много инструментов для автоматизации процессов непрерывной интеграции, тестирования и развертывания. Расскажем о нескольких.
Jenkins — один из самых популярных сервисов. Это инструмент с открытым исходным кодом, позволяющий автоматизировать процессы интеграции, тестирования и развертывания. Преимущество Jenkins перед другими сервисами — 1400 плагинов, созданных сообществом разработчиков и упрощающих работу.
TeamCity — проприетарный сервис для управления сборкой и непрерывной интеграцией от российской компании JetBrains. TeamCity позволяет легко создавать образы Docker, а поддержка Jira и Bugzilla упрощает отслеживание проблем. Сервис хранит все изменения сборки и историю отказов, что облегчает отслеживание статистики. Вдобавок разработчики могут запускать старые сборки и просматривать историю тестирования.
Bamboo CI — разработка Atlassian, распространяемая по лицензии. Инструмент интегрируется с другими сервисами компании — Jira, Confluence и Clover. Bamboo CI способен выполнять параллельное тестирование с быстрой обратной связью. Это простой в освоении инструмент с удобным интерфейсом.
GitLab CI — платформа с набором инструментов для работы с кодом, принадлежащая GitLab Inc. Основная часть функций доступна бесплатно, для остальных нужна покупка лицензии. Bamboo CI напрямую интегрирован с рабочим процессом GitLab и отображает всю информацию о ходе выполнения кода на единой панели инструментов.
CircleCI — проприетарный сервис, разработанный одноименной компанией. Считается одним из лучших инструментов для автоматизации сборки, тестирования и развертывания. Сервис интегрируется с Bitbucket, GitHub и GitHub Enterprise, легко устраняет ошибки, быстро запускает тесты и имеет возможности для кастомизированных настроек. Он легко интегрируется с разными облачными сервисами.
Приложения, для которых метод CI/CD — это не лучшее решение
Пайплайн CI/CD не подходит для больших монолитов — например, банковских приложений, которые обновляются всего несколько раз в год. Кроме того, проблемой может стать устаревшая архитектура некоторых приложений. Реализовать CI/CD в таких случаях бывает непросто. Фактически архитектура приложения может стать серьезным препятствием при переходе на CI/CD.
CI/CD и сервис оркестрации контейнеров Kubernetes
Kubernetes имеет большой список вариантов применения. Его используют для развертывания контейнеров приложений в облаке, планирования пакетных заданий, обработки рабочих нагрузок и выполнения постепенного развертывания. Kubernetes обрабатывает эти операции, используя эффективные алгоритмы оркестровки, которые хорошо масштабируются.
Запуск пайплайна CI/CD — один из основных вариантов использования Kubernetes. Благодаря своей декларативной структуре и возможностям настройки, он помогает пользователю эффективно планировать задания для любого сценария.
Контейнеры позволяют выполнять упаковку и транспортировку приложений стандартными способами переноса. При помощи контейнеров, упрощается масштабирование или отключение сред с переменными рабочими нагрузками.
Создание пайплайна CI/CD — хороший способ разобраться в устройстве Kubernetes тем, кто только начинает его изучать.
Managed Kubernetes
Хотя Kubernetes включает в себя значительное количество встроенных функций и предназначен для упрощения оркестровки контейнеров, его настройка, развертывание и управление могут вызвать затруднения у пользователей. Многие организации не имеют достаточно опыта, необходимого для самостоятельного использования Kubernetes, но не хотят упускать преимущества контейнерных приложений. Managed Kubernetes — хорошее решение этой дилеммы.
Managed Kubernetes, предоставляет пользователю готовое решение для работы. Провайдер заботится о работоспособности кластера Kubernetes, разворачивает виртуальные машины, обновляет кластеры и узлы и обеспечивает резервное копирование.
Yandex Managed Service for Kubernetes
Yandex Managed Service for Kubernetes помогает автоматизировать процессы управления, масштабирования, изменения, обновления и удаления контейнеров.
Сервис предоставляет окружение для удобного управления контейнерами приложений в инфраструктуре Yandex.Cloud. Он упрощает процесс развертывания, масштабирования и обслуживания контейнерной инфраструктуры. Обновление версий, заботу о безопасности и работоспособности берет на себя Yandex.Cloud.
