В данной статье рассмотрим основные варианты организации CI/CD, которые можно реализовать с использованием werf.

Цель организации CI/CD для нас проста: доставить новые изменения в коде до конечного пользователя как можно быстрее. CI/CD состоит из 2‑х частей: CI подразумевает непрерывное слияние изменений в основную кодовую базу, а CD непрерывную доставку этих изменений до пользователя.

Окружение

Production

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

Production-like

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

Staging

Staging — это окружение, в котором происходит финальная проверка перед выкатом на production. Staging даёт возможность полнее протестировать бизнес-функции приложения и обычно это то место, куда идут менеджеры, тестировщики, заказчики.

В случае, если приложение связано с какими либо внешними сервисами, staging — это единственное окружение помимо production, где можно проверить как новая версия работает в связке с реальными версиями внешних систем.

Testing

Testing — это окружение, цель которого: выявить возникшие у приложения проблемы на production окружении. В данном окружении могут работать “долгие” автоматизированные тесты приложения, которые проверяют множество аспектов его работы. Чем больше различий между testing и production, тем больше рисков получить нерабочее приложение после очередного выката, поэтому рекомендуется максимально повторять production окружение (одинаковый софт, версии, библиотеки, IP-адреса и порты, железо и т.д.).

Review

Динамический (временный) контур, используемый разработчиками при разработке для оценки работоспособности написанного кода, первичной оценки работоспособности приложения и проведения таких экспериментов, которые нельзя делать на production-like окружениях.

Особенность review-окружений в том, что их можно создавать динамически в любых количествах (в разумных пределах, насколько позволяют ресурсы). Как правило, создание и удаление такого окружения инициируется разработчиком через CI/CD систему, также такое окружение может быть удалено автоматически после отсутствия активности в течение некоторого времени.

Релизы и CI/CD

Релиз — это оформленная версия приложения с какими-то изменениями с момента предыдущего релиза.

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

В CI/CD подходе релизы делаются часто, и релизы могут содержать мало изменений. Поощряется, чтобы разработчики разбивали новые фичи на такие куски, которые можно сразу обкатать на production-like или production окружениях. Более того, разработчики, которые прониклись таким подходом, сами хотят как можно быстрее пустить новый код в работу и получить обратную связь — после этого опираясь на проверенный код проще делаются новые изменения. До конца доделанным можно считать лишь тот код, который не только написан, но и задействован в production.

В дальнейших разделах мы определим возможные варианты конфигураций workflow и насколько каждый из них соответствует подходам CI/CD.

Что такое pipeline и workflow

С помощью git пользователь вносит изменения в кодовую базу проекта. Каждый коммит в гит активирует так называемый pipeline со стороны CI/CD системы. Pipeline разбит на стадии, которые могут запускаться последовательно или параллельно.

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

Бывают следующие основные типы стадий:

  • Build-and-Publish — сборка образов приложения и их публикация в хранилище образов.
  • Deploy — непосредственно выкат приложения на контур.
  • Cleanup — очистка неиспользуемых образов и связанного кеша из хранилища.

Pull request

Пользователь вносит изменения в кодовую базу путём создания коммитов в git и pull request-ов в CI/CD системе. Обычно pull request — это сущность, которая связывает коммит в git и pipeline (а также позволяет делать review, оставлять комментарии и пр.). В разных CI/CD системах pull request может называться по-разному (Merge Request в GitLab CI) или вообще отсутствовать (Jenkins).

Workflow

Pipeline-ы и стадии внутри pipeline-ов могут быть активированы как автоматически, так и вручную. Способы активации pipeline-ов, их устройство, связь с гит, требуемые действия со стороны пользователя — всё это будет определяться так называемым workflow. Возможно множество вариантов workflow для достижения одной и той же цели. Далее мы рассмотрим те варианты, которые можно реализовать с использованием werf.

Варианты ручного запуска pipeline

Ручной запуск pipeline предполагает:

  • Нажатие кнопки в CI/CD системе (например Gitlab CI).
  • Назначение label в CI/CD системе (например Gitlab CI или Github Actions). Label обычно назначается на pull request и снимается с pull request пользователем или автоматически CI/CD системой во время работы pipeline.
    • Например, пользователь назначает label “run tests” на его pull request и CI/CD система автоматически запускает соответствующий pipeline. Во время работы этого pipeline label “run tests” снимается с pull request. Далее для перезапуска пользователь может опять назначить этот label. И т.д.
    • Label используется как альтернатива кнопкам, либо в случаях когда кнопки не поддерживаются CI/CD системой (например, Github Actions). Для review окружений назначение пользователем label является сигналом к активации review окружения, а его снятие (вручную/автоматом) — к деактивации.
  • Запрос через API CI/CD системы (например через HTTP по определённому url в Github Actions).

Стадия тестирования

Для правильной организации CI/CD критично во время внесения изменений в кодовую базу проекта получать быструю обратную связь в автоматическом режиме с помощью тестов. Причём стадию тестирования можно разбить на 2 условных этапа: на первичном этапе тесты проходят быстро и покрывают большую часть функций, на вторичном этапе тесты могут работать долго и проверять больше аспектов приложение. Первичные тесты обычно запускаются автоматически и их прохождение является обязательным условием для допуска изменений к релизу.

назад
далее