Тема 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 в скором времени.
Этот материал – не редакционный, это – личное мнение его автора. Редакция может не разделять это мнение.
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: