Когда и зачем нужен CI/CD
Скорость сборки продукта — важное конкурентное преимущество в разработке программного обеспечения. То, что раньше делалось месяцами, сегодня выполняется за считанные дни без потери качества. Путь к ускорению релизов лежит через автоматизацию и внедрение CI/CD.
В статье разберём, когда и зачем нужен CI/CD, но перед этим, расскажем, как устроена методология и почему эффективнее внедрить её, чем деплоить вручную.
Что такое CI/CD
CI/CD — это одна из DevOps практик, которая позволяет разработчикам чаще и надёжнее развёртывать изменения ПО, свести к минимуму ошибки, повысить темпы сборки и качество разрабатываемого продукта. Представляет собой комбинацию continuous integration и continuous delivery.
CI, или непрерывная интеграция — процесс постоянной разработки ПО с интеграцией в основную ветвь. Автоматически собирает софт, тестирует его и оповещает, если что-то идёт не так.
CD, или непрерывная доставка — процесс постоянной доставки ПО до потребителя. Обеспечивает разработку проекта небольшими частями и гарантирует, что он может быть отдан в релиз в любое время без дополнительных ручных проверок.
Как выглядит цикл CI/CD:
Разработчик пишет код, проводит начальное тестирование, чтобы не было ошибок, и фиксирует изменения в своей рабочей ветке. Затем соединяет модифицированный код с рабочим кодом из основной ветки.
Система, выбранная инструментом CI, замечает, что в коде произошли изменения и запускает автоматическую сборку и автоматическое тестирование программы.
Если автоматическое тестирование прошло успешно, ПО отдаётся для ручного тестирования команде тестировщиков.
После исправления недочётов, обнаруженных во время ручного тестирования, запускается автоматизированная установка ПО на серверах компании.
Осуществляется поддержка новой версии программы и её мониторинг.
Собираются запросы на исправление недочётов и багов, разработчик вносит изменения в код, и процесс повторяется.
Основное преимущество CI/CD в том, что разработчику нужно только написать код, а остальные процессы по тестированию, сборке и доставке проходят автоматически.
Как было до CI/CD
Вернёмся на несколько лет назад и вспомним, как деплоили вручную на примере обновления интерфейса сайта.
Обычно у разработчика был тестовый сервер, куда он доставлял код и где выполнял QA-тесты. На практике это выглядело так: он обновлял страницу и смотрел, появились ли изменения. Если что-то отображалось некорректно, тут же подправлял код, закидывал новую версию и снова проверял. После устранения всех ошибок начиналась работа на серверах клиента — разработчик копировал софт в продакшен в момент наименьшей активности пользователей.
Если на сервере все отображалось корректно, задача считалась выполненной. Если нет, начинался быстрый поиск ошибок. В дальнейшем, чтобы исправить какой-то баг или выпустить новую фичу, разработчику снова нужно было идти на сервер и менять все вручную.
Сегодня деплоить руками — это антипаттерн, который не отвечает на вызовы рынка. Хотя по-прежнему существуют компании, у которых есть сайты с большой посещаемостью, — они заходят туда в середине рабочего дня, ставят заглушку и начинают править код прямо на продакшене. Такие простои критичны для бизнеса.
При этом сам по себе деплой — рутинная задача. Нужно скомпилировать код, перенести все файлы на сервер, выполнить миграции, поправить конфигурации и др. Когда вы делаете все вручную, это отнимает много времени, и всегда можно что-то упустить. В итоге на подготовку кода к релизу уйдут месяцы, что слишком долго в условиях постоянной конкуренции.
Автоматизированный CI/CD-пайплайн позволяет вам доставлять изменения еженедельно, ежедневно или даже ежечасно. Если всё настроено правильно, то вы деплоите приложения на сервер с помощью всего одной команды.
Почему CI/CD — это важно
Существует понятие time to market — это время, которое компания тратит на реализацию и выпуск продукта. Чем ниже time to market, тем быстрее зарабатываются деньги для бизнеса. Если ваш конкурент за день зарелизил новую фичу, а вам на то, чтобы её разработать и внедрить требуется неделя — это плохо, вы теряете деньги, которые могли бы заработать.
Внедрение CI/CD позволяет ускорить time to market. Это полезно для поддержания конкурентоспособности — благодаря частым релизам продуктовые менеджеры и маркетологи могут активнее участвовать в разработке.
Плюс, возможность рано и часто тестировать новые фичи с участием пользователей в преподакшене или продакшн-окружении позволяет проверить, насколько эти фичи решают проблемы пользователей. Возможно, они не соответствуют запросам ЦА, и не стоит тратить месяцы на реализацию такой функциональности.
Какие проблемы решает CI/CD
CI/CD позволяет свести к нулю ручной труд при выполнении рутинных операций: сборки и выкладки новых версий кода. Все это делается по кнопке с помощью специальных инструментов Jenkins, GitLab CI и др.
За счёт автоматизации процесс CI/CD решает ряд важных проблем:
Отсеивает некоторый процент ошибок на пути в продакшн. Цена ошибок в коде велика, и часто их причиной становится человеческий фактор. Важным этапом выпуска ПО считается тестирование кода, но, чтобы выполнить его тщательно, нужно много времени. Сценарии ручного тестирования требуют множества повторений и высокой концентрации. Даже самый ответственный тестировщик может невольно отвлечься и повторить те же шаги с небольшим отличием. Центральная часть любого CI/CD-пайплайна — набор автоматизированных тестов. Автоматизация тестирования гарантирует, что тесты выполняются точно, а результаты — будут надёжны.
Улучшает качество кода. CI/CD автоматизирует запуск множества проверок: unit-тестирования, интеграционного тестирования и др. Это позволяет разработчикам заниматься программированием и кодом, а не тратить время на разбор инцидентов и поиск их причин.
Устраняет разобщённость между разработкой и операционной деятельностью. CI/CD — это единая точка коммуникации контроля разработки и интеграции ПО. Вы можете задействовать в создании продукта самых разных специалистов и добиться прозрачности процесса разработки и сотрудничества команд друг с другом.
Повышает скорость внедрения нового функционала. Вы можете настроить единообразный и простой интерфейс для всех команд разработчиков и организовать их одновременную работу над разными частями проекта. Каждая команда будет создавать и развёртывать службы, которыми она владеет, не влияя на другие команды и не нарушая их работу. Плюс, внедрение CI/CD влечёт повышение квалификации команды и создаёт среду, где каждый специалист занят своим делом.
Позволяет быстро исправлять баги в софте. CI/CD хранит историю сборок за какой-то промежуток времени. При необходимости вы можете увидеть, когда было то или иное изменение и откатиться назад, если что-то пошло не так. Чем раньше обнаружен баг, тем дешевле его исправление. Во-первых, потому что разработчик все ещё работает над той же частью программного кода, ему не нужно переключаться между контекстами, и он вносит правки буквально «на лету». Во-вторых, потому что ветки кода не успели размножиться на последующие релизы, и не придётся править один баг в нескольких местах.
Решая перечисленные проблемы, CI/CD нормализует работу и коммуникацию бизнеса с IT — исчезают противоречия в духе: «Кто кому должен и кто плохо работает». Построение CI/CD-пайплайна делает процесс разработки и выпуска ПО более компактным и эффективным. Пока компьютеры выполняют рутину, разработчики могут сосредоточиться на решении бизнес-задач и проведении экспериментов.
Когда нужен CI/CD
CI/CD стоит применять почти на всех проектах. Да, вы потратите немало времени, когда первый раз будете настраивать пайплайн, но обязательно ощутите отдачу — на выкатку в продакшн будет уходить несколько минут, хотя раньше это занимало целый день.
При этом есть два случая, когда польза CI/CD спорна:
Когда нет потребности в автоматизации. Если это небольшая компания или стартап, где деплоем занимаются два человека, им пока не нужен CI/CD. Стоит подождать, пока проект вырастет до точки, где ему понадобится автоматизация, а внедрение CI/CD принесет больше плюсов, чем минусов.
Когда в компании присутствуют архаические методы. Например, в некоторых государственных компаниях используется софт, которому уже больше 10–15 лет и который уже находится в какой-то итерации. В такой ситуации проблематично настроить автоматическую доставку, и разработчику проще вручную вносить изменения на продакшн сервера.
За исключением описанных случаев все больше компаний понимают необходимость процесса автоматизации, и роль CI/CD возрастает.
Вместо заключения
Подведем итоги и ответим, зачем все-таки нужен CI/CD:
Чтобы получать ожидаемый результат от деплоя. Если вы один раз описали инфраструктуру или какой-то процесс в виде кода, то каждый раз, когда будут выполняться процессы автоматического развёртывания, они будут одинаковыми. Так исключается ситуация, когда вчера вы деплоили одним способом, а сегодня кто-то что-то поправил, и все работает не так, и вам нужно искать причину почему.
Чтобы свести к минимуму возникающие ошибки. Каждый пропущенный баг, уязвимость или сбой в бизнес-процессах — это дополнительные 1–2 недели к сроку релиза. CI/CD снижает процент ошибок на пути в продакшн за счет исключения человеческого фактора и автоматизации тестирования.
Чтобы ускорить срок вывода продукта на рынок. Задача CI/CD-пайплайна — быстро и часто доставлять пользователям работающее ПО.
Разобраться в принципах CI/CD, научиться самостоятельно создавать сложные пайплайны и понять, как ускорить цикл разработки с минимальными рисками вам поможет видеокурс «CI/CD на примере Gitlab CI».
Все занятия проходят в Личном кабинете Слёрма — вы самостоятельно выбираете, когда смотреть их. После каждой темы идет практическое задание — его вы выполняете на стендах платформы.
Курс рассчитан на тех, кто уже работал Git и Docker, хорошо разбирается Linux. Подойдет DevOps-инженерам, разработчикам компаний, где нет выделенного DevOps, и системным администраторам.
