Что такое CI/CD, как он работает и когда понадобится на проекте. Лайфхаки и bad practices

Тема CI/CD включает много технологий из сферы DevOps и охватить их все в одной статье невозможно, поэтому считайте, что это некая «обзорная экскурсия». В блоге вы узнаете, как внедрить этот процесс в своей команде и применять CI/CD на практике, а также о bad practices.

Что такое CI/CD

CI/CD является распространенной DevOps-практикой. CI (Continuous Integration) – это непрерывная интеграция, а CD (Continuous Delivery) – непрерывная доставка. Этот набор методик позволяет разработчикам чаще и надежнее развертывать изменения в программном обеспечении.

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

Поясним суть CI/CD через четыре W:

• What?

Все началось с DevOps. В начале 2000-х это направление объединило разработку и тестирование и привлечение к работе большего количества команд. Девопсы стали распространять принципы Agilе на разработку. Специалисты стремились еще больше сократить время разработки, получать более качественный код и увеличить количество релизов. Это послужило основой CI/CD. Здесь сохраняется фокус и на инструментах и ​​на взаимодействии в команде. 

• Why?

CI/CD необходим для автоматизации рутинных задач. Среди них – сборка и преобразование исходного кода в артефакт, отправка его на сервер, проверка тестами и т.п. Чем больше становится проект, тем чаще в код вносятся изменения. Донесение пользователю занимает много времени. А внедрение CI/CD экономит этот ресурс.

• Where?

Используется в больших и активно растущих проектах, где увеличивается количество пользователей, кода и апдейтов.

• Who?

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

CI: с чего все начинается

Непрерывная интеграция – ключевой элемент DevOps-подхода. Именно он способствует слаженной работе команды и получению обратной связи. Участники разработки публикуют изменения как можно чаще, чтобы как можно раньше увидеть фидбек.

Согласно принципу CI изменения отображаются в системе контроля версий. В настоящее время стандартом для большинства компаний является Git. Этот инструмент опенсорный, удобный и гибкий. Но вспомним и другие: Mercurial, Subversion или SVN (упокой его душу, страшное легаси), Concurrent Versions System, GNU Bazaar, BitKeeper.

Также есть сервисы, предлагающие систему контроля версий в качестве услуги. Они могут быть в виде selfhosted или cloud. Основными игроками на этом рынке являются Bitbucket, GitLab и GitHub.

Системы контроля позволяют совместно работать над одним исходным кодом. Они сохраняют историю изменений и имеют удобные инструменты для разветвления, слияния и разрешения конфликтов, отслеживания и обсуждения корректировок. Также системы контроля версий подразумевают версионирование, которое во многом является ключевым аспектом CI/CD. Об этой возможности дальше поговорим отдельно.

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

Однако есть перечень действий, касающихся CI:

• детектирование изменений в системе контроля версий (например, клонирование репозитория с нуля или стягивание последних изменений);
• сборка кода и юнит-тесты (это касается компилируемых языков);
• фидбек.

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

Одним из самых популярных инструментов здесь является Jenkins. Часто упоминают о TravisCI, CircleCI, Bamboo, TeamCity, а также GitLab CI и GitHub Actions как CI/CD extensions для этих SCM-платформ. Они помогают упростить и ускорить разработку. За счет стандартизации процессов и их автоматизации девелопер может сосредоточиться на основной задаче – написании качественного кода. Время ожидания merge day (дня слияния) с заливкой огромного пакета изменений останутся в прошлом.

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

Bad practices в CI

В интернете можно найти несколько популярных документов с подробным описанием bad practices для CI/CD-процесса. Некоторые пункты противоречивы, но многие из них правильны и полезны:

• Структура проекта в репозитории не соответствует принципу модульности.

При любой возможности следует отказаться от построения монолита. Это избавит от множества проблем. Например, если вы вносите изменения в определенный субмодуль, можете собрать и проверить только его, а не весь проект. Так сэкономите много времени.

• Использование взаимозаменяемых плагинов и инструментов.

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

• Объединение различных задач в один логический stage в пайплайне.

Билд, тест, анализ и другие логические единицы должны быть представлены в отдельных блоках. Таким образом, вы быстро локализируете проблему без длительного изучения логов и попытки разобраться, что пошло не так.

• Игнорирование локальных сборников.

Помните о человеческом факторе. Из-за небольшой ошибки или похожей проблемы можно потерять много личного времени и времени CI-сервера.

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

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

CD: храним, проверяем, доставляем

Вторая часть процесса – Continuous Delivery – предусматривает следующие шаги:

• Хранение. После компиляции или сборки кода вы получаете артефакт. Это широкое понятие с множеством вариаций: Maven-артефакты, Python-артефакты, NuGet-репозитории из .NET, RubyGems, Docker Image и даже ZIP-архивы с JS-файлами. Эти документы можно хранить локально, но не стоит. С компьютером или разработчиком всегда что-то может произойти. В результате команда не получит артефакт. Потому храните артефакты в отдельных репозиториях. Это повышает безопасность и обеспечивает гибкие возможности: централизованное или структурированное хранение, версионирование и т.д.
• Проверка. Полученный артефакт, как и в CI-части, следует тестировать. Вы должны понять, правильно ли он собрался, соответствует ли содержимое определенным требованиям безопасности, политики и чистоты кода. Имеются в виду, прежде всего, статические анализаторы (динамические касаются рабочего приложения после деплоя). Так вы убедитесь, что не отправите в деплой что-нибудь неправильное.
• Деплой . После выбора инструментов (из соображений неповторимости и проверки артефактов на соответствие заданным профилям) их можно деплоить на рабочие мощности. Вариантов реализации много. Это может быть локальный компьютер, Kubernetes-кластер, выделенный сервер, облако от AWS или Azure и т.д. Выбор зависит от проекта и требований заказчика.
• Мониторинг. Нельзя следовать принципу «задеплоил и забыл». Вы должны следить за работой программы. Настройте систему мониторинга с отправкой сообщений, отслеживайте результаты, анализируйте метрики и аллерты при сбоях. Это позволит вам оперативно решать проблемы с минимальным простоем программы.

Bad practices в CD

• Деплой локально собранного артефакта.

Так делать нельзя ни при каких обстоятельствах. Ваша система сборки и деплой на локальной машине не стандартизована и общая. Артефакт может отличаться от аналога в системе CI. Поэтому всегда используйте пайплайн для сборки и деплой.

• Хранилище артефактов не используется.

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

• Отсутствие стратегии при поломке артефакта.

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

• Несоответствие между исходным кодом и получаемым артефактом.

У вас должна быть прозрачная система версионирования. Конкретная версия собранного артефакта должна соответствовать состоянию исходного кода, имеющегося в системе контроля версий. Если эти параметры не консистентны, то вы не будете уверены, что артефакт собран из этого конкретного состояния исходного кода.

В продолжении блога мы расскажем о пайплайнах и  версионировании – читайте на Highload в скором времени.