Продолжаем тему CI/CD (Continuous Integration, Continuous Delivery): в предыдущей части блога мы разобрались, что это за технология и как она может сэкономить рабочее время разработчику. Теперь расскажем о нюансах работы с CI/CD-пайплайнами, плохих практиках, а также версионировании как способе менеджмента изменений в коде.
При объединении CI и CD получаются пайплайны. Все о них слышали, но часто трактуют это понятие по-разному. В одном проекте пайплайном могут назвать отдельную фичу или задачу. Это отчасти верно. И действительно, пайплайн — это последовательность определенных действий, разделенных на логические единицы: сборка проекта, тесты, загрузка артефактов в хранилище, деплой и т.д.
Чтобы избежать недоразумений, на старте проекта или присоединяясь к новой команде согласуйте со всеми привлеченными командами одно значение пайплайна. У вас могут быть CI-пайплайны, CD-пайплайны или их комбинации. Без окончательного определения термина вы будете тратить время на постоянные уточнения. Кто-то создаст у Jira тикет с фразой “У меня не работает пайплайн”. И здесь у вас возникнет вопрос: речь о проблемах со сборником или деплоем?
Учить вас создавать пайплайны в этой статье не будем, но базовые моменты рассмотрим. В первую очередь определите, кто, чем и как занят. Затем зафиксируйте желаемый результат. Пайплайн должен иметь смысл. А главное, им должны пользоваться все. Часто бывает, что кто-то создал хороший пайплайн, но все делают по старинке, как привыкли. Обязательно объясняйте коллегам пользу от введения новых подходов. Ведь CI/CD — это постоянное взаимодействие со всеми членами команды.
Рассмотрим универсальную модель решения любой задачи. Начнем с получения разработчиком таска – в Jira или на митинге. Далее он создает отдельный бранч в системе контроля версий, пишет код или вносит исправления, локально тестирует, создает пул реквест и просит кого-нибудь отревьюить результат. Затем остается соединить эту ветку с основной, собрать и задеплоить на dev-окружение.
Допустим, на все это вы потратили неделю. 90-95% времени ушло на написание кода, а на сопутствующие действия и деплой понадобилось, скажем, 2 часа. Это логическое соотношение. Но если на исправление микробага нужно 10 минут, а на сборку и деплой ушел час, то в процессе есть проблемы. Если придется исправлять по 10 микробагов в день, тогда все время будет идти на сборку и деплой.
Ситуация имеет два решения:
А еще важно сделать локальную среду сборки приближенной к серверу непрерывной интеграции. Это также обезопасит от проблем в будущем. Уделяйте внимание стандартизации процессов. По нормам CI/CD, любая фича считается выпущенной глобально только тогда, когда пройдет все стадии пайплайна. Исключений быть не может. Иначе теряется суть CI/CD.
Помните: даже самые лучшие проверки без фидбека лишают смысла пайплайное построение. Выявляя проблемы, важно доносить их результаты людям, вызвавшим сбои. Сам же процесс необходимо останавливать без внесения изменений. Так вы предотвратите проблемы на деплое и скорректируете работу в будущем.
Версионировать нужно не только код программы, но и код пайплайнов. Естественно, логика пайплайнов лежит в системе контроля версий. Это отчасти решает проблему со случайным удалением важных фрагментов, но в идеале лучше версионировать и это.
Если у вас есть валидные плагины, которые решают те же задачи, используйте именно их, а не эти скрипты. В конце концов они и созданы для таких целей.
Все должно происходить по плану. Нельзя, например, деплоить что-нибудь на продакшен, а затем запускать тестирование.
Цепочка действий должна выполняться от начала до конца. Иногда есть соблазн пропустить какой-то этап. Например, в шаге тестов предусмотрено 1000 проверок, но 1-2 из них проблемные, они разрушают весь пайплайн. Можно пропустить шаг, но не стоит. В таком случае лучше попросить QA-команду устранить сбои или удалить те проблемные тесты, а оставшиеся 998 пусть работают дальше.
Это касается, прежде всего, CI-части. Ручной старт пайплайнов ломает логику быстрой проверки и получения фидбека. Но для CD-части это иногда допустимо. Вы можете запускать отдельные пайплайны вручную, если команда или заказчик не созрели до полной автоматизации и им нужно взвешенно подходить к целям деплоя.
Недопустимо в пайплайнах. Причины такие же, как в CI- и CD-частях.
Вы должны действовать по четкому сценарию. Иначе можно создать миллион джоб- и пайплайнов для разных приложений или с разным содержанием, но дублирующих друг друга с разницей в одно значение. Проще сделать стандартный пайплайн, в котором меняется определенный вариативный параметр.
Джоб- и пайплайнам следует подобрать наименование. Почему это важно? При неудачном нейминге на CI-сервере могут возникать дубликаты. Это особенно распространено на крупных проектах, где несколько команд занимаются одинаковыми задачами. Кроме этого, невнятные названия усложняют поиск нужных джобов. Вам придется тратить время, чтобы определить, что делает та или иная джоба, или это вам действительно нужно.
Здесь все просто: вы должны убедиться в качестве продукта до его деплоя на продакшене.
Можно что-то протестовать уже на продакшене. Для этого существует особая техника: выбираете несколько тестов, запускаете их и креститесь… Если опустить иронию, как вы могли понять, так делать нельзя.
Жизненный цикл программы так или иначе связан с ее версиями. Без упоминания версии непонятно, о каком приложении идет речь, какой у него функционал, исправлены ли баги и т.д. Также без версионирования существует большой риск получить несовместимость между отдельными модулями или блоками, используемыми в приложении. К примеру, при переходе с версии 3.1 на 4.0 может перестать работать основной функционал. Стандартное версионирование подразумевает определенную совместимость продуктов.
Основная функция версий – навигация. Это можно сравнить с GPS-метками только для кода.
Благодаря обозначению версий вы свяжете определенное состояние кода с конкретными артефактами или версией приложения для пользователей. Так легче ориентироваться в текущем положении дел. Для версионирования можно использовать:
Это самый распространенный подход. Он предполагает несколько вариантов. Простейшие номера по порядку: 1, 2, 3… Также они могут иметь дробную часть: 1.1 или 2.5. Популярная троичная система: с мажорной версией, минорной и фикс-версией. Тогда последняя цифра изменяется при фиксации багов без кардинальных изменений в функционале. Средняя цифра обновляется с появлением новых фич и обратной совместимости программы. Первая мажорная цифра корректируется при большом апдейте или несовместимости с прошлым релизом.
Вариант обозначения только буквами латинского алфавита не очень распространен из-за ограниченности набора символов. Буквы могут использоваться в троичной системе для фикс-версии: 1.3.b, 4.2.c и т.п.
Обозначают этап процесса разработки продукта. Это могут быть альфа- и бета-версии, релиз-кандидаты, сервис-релизы и т.д.
Простая и понятная система — с универсальным порядковым элементом в виде даты, когда была запущена новая версия.
Этот подход удобен с точки зрения маркетинга, поскольку пользователю легче запоминать слова, а не набор цифр. В качестве примера — подход к версионированию в Ubuntu, где версия может называться вроде Focal Fossa. Если сомневаетесь, какую концепцию для наименования версий выбрать или вообще не хотите тратить на это время, советуем брать SemVer — семантическое версионирование. Этот стандарт создал соучредитель GitHub Том Престон Вернер. SemVer сочетает в себе последовательность чисел с троичной системой. Позволяет использовать этапы сборки или дополнительные метки типа частей, хешей и комитов.
В любом крупном проекте далеко не один разработчик и даже не одна команда. Среди специалистов могут быть несколько разработчиков, тестировщиков, отдельно релиз- и security team. Однако не все из них могут знать о существовании смежных команд, не говоря уже об их задачах. Если не считать этого, то некоторые специалисты или команды начнут работать над одной задачей, но не будут знать всех нюансов. Получится два полуготовых решения. Для CI/CD такая ситуация неприемлема.
При внедрении CI/CD-процессов кому-то придется изменять обычное течение работы. Поэтому необходимо правильно доносить людям причины перемен. Не потому, что кому так захотелось, а потому, что так лучше для проекта. В конце концов, авторы покаскадной модели, поставившие планировку на первое место, в этом были правы.Строя пайплайны, нужно заранее обсудить все нюансы. А дальше остается держать руку на пульсе перемен и корректировать работу. Не зря же существует трактовка CI как Continuous Improvement – регулярные улучшения. К внедрению CI/CD коллег следует готовить заранее. Иногда для постройки пайплайна достаточно нескольких минут и десяток кликов. Но обычно это более длительный процесс. Поинтересуйтесь ходом работ и планами каждой команды. В противном случае могут возникнуть серьезные трудности с интеграцией новых идей в уже созданный пайплайн.
Время – бесспорно самый ценный ресурс, и CI/CD экономит его.
Интегрировать CI/CD можно в любой проект, где мануальные действия отстают по темпу изменений кода. Но следует помнить и то, что результаты должны окупать затраченные усилия.
В конце концов, IT — это не технологии ради технологий. Это, прежде всего, бизнес. Если использование CI/CD занимает больше, чем экономит, задумайтесь, что пошло не так.
В благословенные офисные времена, когда не было большой войны и коронавируса, люди гораздо больше общались…
Вот две истории из собственного опыта, с тех пор, когда только начинал делать свою карьеру…
«Ты же программист». За свою жизнь я много раз слышал эту фразу. От всех. Кто…
Отличные новости! Если вы пропустили, GitHub Copilot — это уже не отдельный продукт, а набор…
Несколько месяцев назад мы с командой Promodo (агентство инвестировало в продукт более $100 000) запустили…
Пару дней назад прочитал сообщение о том, что хорошие курсы могут стать альтернативой классическому образованию.…