Пайплайн CI/CD: что это такое, как применяется в разработке и bad practices

Продолжаем тему CI/CD (Continuous Integration, Continuous Delivery): в предыдущей части блога мы разобрались, что это за технология и как она может сэкономить рабочее время разработчику. Теперь расскажем о нюансах работы с CI/CD-пайплайнами, плохих практиках, а также версионировании как способе менеджмента изменений в коде.

Пайплайн

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

Чтобы избежать недоразумений, на старте проекта или присоединяясь к новой команде согласуйте со всеми привлеченными командами одно значение пайплайна. У вас могут быть CI-пайплайны, CD-пайплайны или их комбинации. Без окончательного определения термина вы будете тратить время на постоянные уточнения. Кто-то создаст у Jira тикет с фразой “У меня не работает пайплайн”. И здесь у вас возникнет вопрос: речь о проблемах со сборником или деплоем?

Учить вас создавать пайплайны в этой статье не будем, но базовые моменты рассмотрим. В первую очередь определите, кто, чем и как занят. Затем зафиксируйте желаемый результат. Пайплайн должен иметь смысл. А главное, им должны пользоваться все. Часто бывает, что кто-то создал хороший пайплайн, но все делают по старинке, как привыкли. Обязательно объясняйте коллегам пользу от введения новых подходов. Ведь CI/CD — это постоянное взаимодействие со всеми членами команды.

Типичный сценарий применения пайплайна

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

Допустим, на все это вы потратили неделю. 90-95% времени ушло на написание кода, а на сопутствующие действия и деплой понадобилось, скажем, 2 часа. Это логическое соотношение. Но если на исправление микробага нужно 10 минут, а на сборку и деплой ушел час, то в процессе есть проблемы. Если придется исправлять по 10 микробагов в день,  тогда все время будет идти на сборку и деплой.

Ситуация имеет два решения:

• Подвинуть изменения во времени. Вы можете оттягивать момент слияния изменений в основной бранч. Так вы увеличите количество изменений в пул реквесте, который создадите впоследствии. Однако ревьюировать полотно кода вместо пары строк сложно и рискованно.
• Настройка CI/CD-пайплайн. Этот инструмент автоматически собирает проект, тестирует и деплоит на dev-окружении. Такой подход экономит время и сокращает вероятность сбоев из-за человеческого фактора.

А еще важно сделать локальную среду сборки приближенной к серверу непрерывной интеграции. Это также обезопасит от проблем в будущем. Уделяйте внимание стандартизации процессов. По нормам CI/CD, любая фича считается выпущенной глобально только тогда, когда пройдет все стадии пайплайна. Исключений быть не может. Иначе теряется суть CI/CD. В теме пайплайнов стоит хотя бы чуть-чуть затронуть чекеры. Если мы имеем в виду анализ исходного кода, то это статический анализ. Он касается качества кода, покрытия тестами, поиска уязвимых мест. А в случае тестирования программы, которая уже задеплоена в окружение, это динамический анализ.

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

Bad practices в пайплайнах

• Связанные с пайплайном ресурсы не версионируются.

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

• Использование shell-скриптов.

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

• Неверная последовательность пайплайн-стейджей.

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

• Пропуск шагов в пайплайне.

Цепочка действий должна выполняться от начала до конца. Иногда есть соблазн пропустить какой-то этап. Например, в шаге тестов предусмотрено 1000 проверок, но 1-2 из них проблемные, они разрушают весь пайплайн. Можно пропустить шаг, но не стоит. В таком случае лучше попросить QA-команду устранить сбои или удалить те проблемные тесты, а оставшиеся 998 пусть работают дальше.

• Запуск некоторых пайплайнов вручную.
Онлайн-курс "Business English" від Laba.
Вивчіть базу граматики, лексики та вокабуляру.Використовуйте англійську в спонтанній розмові з колегами та клієнтами.Прокачайте її до впевненого В1 — для розвитку кар’єри в бізнесі.
Приєднатись до курсу

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

• Отсутствие уведомлений.

Недопустимо в пайплайнах. Причины такие же, как в CI- и CD-частях.

• Неиспользование параметризированных задач.

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

• Отсутствие нейминга или неумение его делать.

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

• Недостаток тестов на продообразном stage-окружении.

Здесь все просто: вы должны убедиться в качестве продукта до его деплоя на продакшене.

• Запуск тестов на продакшене.

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

Версионирование как способ менеджмента изменений в коде

Жизненный цикл программы так или иначе связан с ее версиями. Без упоминания версии непонятно, о каком приложении идет речь, какой у него функционал, исправлены ли баги и т.д. Также без версионирования существует большой риск получить несовместимость между отдельными модулями или блоками, используемыми в приложении. К примеру, при переходе с версии 3.1 на 4.0 может перестать работать основной функционал. Стандартное версионирование подразумевает определенную совместимость продуктов.

Основная функция версий – навигация. Это можно сравнить с GPS-метками только для кода.

Благодаря обозначению версий вы свяжете определенное состояние кода с конкретными артефактами или версией приложения для пользователей. Так легче ориентироваться в текущем положении дел. Для версионирования можно использовать:

• Числовые версии.

Это самый распространенный подход. Он предполагает несколько вариантов. Простейшие номера по порядку: 1, 2, 3… Также они могут иметь дробную часть: 1.1 или 2.5. Популярная троичная система: с мажорной версией, минорной и фикс-версией. Тогда последняя цифра изменяется при фиксации багов без кардинальных изменений в функционале. Средняя цифра обновляется с появлением новых фич и обратной совместимости программы. Первая мажорная цифра корректируется при большом апдейте или несовместимости с прошлым релизом.

• Буквенные версии.

Вариант обозначения только буквами латинского алфавита не очень распространен из-за ограниченности набора символов. Буквы могут использоваться в троичной системе для фикс-версии: 1.3.b, 4.2.c и т.п.

• Этапные версии.

Обозначают этап процесса разработки продукта. Это могут быть альфа- и бета-версии, релиз-кандидаты, сервис-релизы и т.д.

• Календарная версия.

Простая и понятная система — с универсальным порядковым элементом в виде даты, когда была запущена новая версия.

• Именные версии.

Этот подход удобен с точки зрения маркетинга, поскольку пользователю легче запоминать слова, а не набор цифр. В качестве примера — подход к версионированию в Ubuntu, где версия может называться вроде Focal Fossa. Если сомневаетесь, какую концепцию для наименования версий выбрать или вообще не хотите тратить на это время, советуем брать SemVer — семантическое версионирование. Этот стандарт создал соучредитель GitHub Том Престон Вернер. SemVer сочетает в себе последовательность чисел с троичной системой. Позволяет использовать этапы сборки или дополнительные метки типа частей, хешей и комитов. Попав в действующий проект, вам остается принять существующую систему версионирования. Единственное – убедитесь, что концепция подробно описана в Confluence или другой wiki-системе проекта. В документе должно быть описано, как проводится версионирование, как оно связано с процессом разработки, как команда с ним взаимодействует, какой этап релизов и т.д. Таким образом, все участники разработки будут понимать, что происходит на проекте.

Взаимодействие с командами

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

При внедрении CI/CD-процессов кому-то придется изменять обычное течение работы. Поэтому необходимо правильно доносить людям причины перемен. Не потому, что кому так захотелось, а потому, что так лучше для проекта. В конце концов, авторы покаскадной модели, поставившие планировку на первое место, в этом были правы.Строя пайплайны, нужно заранее обсудить все нюансы. А дальше остается держать руку на пульсе перемен и корректировать работу. Не зря же существует трактовка CI как Continuous Improvement – ​​регулярные улучшения. К внедрению CI/CD коллег следует готовить заранее. Иногда для постройки пайплайна достаточно нескольких минут и десяток кликов. Но обычно это более длительный процесс. Поинтересуйтесь ходом работ и планами каждой команды. В противном случае могут возникнуть серьезные трудности с интеграцией новых идей в уже созданный пайплайн.

Сопоставляйте усилия и результаты

Время – бесспорно самый ценный ресурс, и CI/CD экономит его.

Интегрировать CI/CD можно в любой проект, где мануальные действия отстают по темпу изменений кода. Но следует помнить и то, что результаты должны окупать затраченные усилия.

В конце концов, IT — это не технологии ради технологий. Это, прежде всего, бизнес. Если использование CI/CD занимает больше, чем экономит, задумайтесь, что пошло не так.