Внедряем CI/CD: зачем, как и что в результате

Вы можете использовать любую модель разработки ПО или приложений, но для того, чтобы добиваться нужных бизнес-результатов, ваши релизы должны быть постоянными и своевременными. Сегодня важно предоставлять бизнесу IT-решения с любой скоростью, в которой он нуждается. Этого позволяет достичь такая практика DevOps-подхода, как CI/CD — непрерывная интеграция (Continuous Integration) и непрерывное развертывание (continuous deployment) ПО. В этой статье мы расскажем, что может качественно измениться для продуктовых команд и бизнеса с внедрением CI/CD; как на практике происходит внедрение этой методологии; когда CI/СD работает, а когда можно обойтись без него.

Гибкая разработка Agile стала популярна и даже потеснила традиционную каскадную модель Waterfall именно благодаря тому, что применяемые в ней методологии позволяют выпускать IT-продукты быстрее. Тем не менее классическую Waterfall все еще успешно используют в тех проектах, где важны четко выстроенные процессы, заранее определенные сроки и бюджет. И где уже сформирована обширная база технической документации (СНиПы и спецификации, четкие инструкции и правила каждого процесса), на основе которой можно написать неизменяемые требования к новому ПО. Это, например, проекты в космической, военной и медицинской отраслях, в авиастроении и финансовом секторе. Здесь также важно выкладывать релизы своевременно, поскольку есть четкие сроки, которые нельзя сдвигать.

Однако в основном для сегодняшних требований рынка больше подходят гибкие практики разработки. Они ставят во главу угла итеративную поставку работающего ПО, небольшие быстрые приращения и автоматизацию. Agile выполняет несколько операций параллельно с рабочим процессом непрерывной интеграции и непрерывного развертывания (CI/CD) — сочетание этих методологий позволяет максимально ускорить релиз IT-продукта.

Мы подошли вплотную к непрерывной интеграции (CI) — основной рекомендации Agile и DevOps. Ориентируясь на нее, множество разработчиков проекта интегрируют код из своих веток в центральный репозиторий как можно раньше и достаточно часто (несколько раз в день). Перед интеграцией новый код, а затем его обновления проверяют автоматизированные модульные, интеграционные и другие тесты. Это позволяет команде разработчиков обнаруживать проблемы в коде на самых ранних стадиях, тратить меньше времени на их поиск и сосредотачивать внимание на создании новых функций. Однако на написание качественных тестов может уйти немало времени.

После успешно пройденных тестов изменения становятся доступны для просмотра в общей ветке кода, а у разработчиков появляется возможность создавать «запросы на включение изменений» (pull requests). После завершения описанного процесса циклы последующего рецензирования, проверки и исправления ошибок продолжаются на базе интегрированной основной ветви. Все работают с одной версией кода, поскольку в основе процесса CI лежит система контроля версий исходного кода. Помимо нее и инструментов для автоматизированных проверок качества кода используются еще инструменты проверки стиля синтаксиса, автоматизации сборки и развертывания и другие.

Мы подробно остановились на описании непрерывной интеграции для того, чтобы показать: CI помогает обеспечивать быструю выкладку релизов за счет простых, но грамотно подобранных под проект инструментов автоматизации. Каждый из них выполняет свой набор функций для полного SDLC (Software Development Life Cycle). Удобно, когда этот подбор можно осуществлять на единой платформе. Ей как раз и является платформа управления кодом GitLab CI.

DevOps-команда Git in Sky предпочитает в своей работе над проектами инструмент автоматизации разработки, который значительно экономит время тестирования и сборки и который мы успешно применяем своей практике уже более 8 лет — это GitLab CI. Как инструмент непрерывной интеграции для своевременной выкладки релизов его можно эффективно использовать в разных моделях разработки: как в итеративных и инкрементных, так и в традиционных — водопад и подобные. Методы регулярной автоматизированной сборки проекта, применяемые в GitLab CI, помогают оперативно выявлять дефекты и решать интеграционные проблемы. Ключевое слово здесь — «оперативно».

GitLab CI не требует использования вспомогательного инструментария, имеет открытый исходный код и позволяет создавать законченные пайплайн-решения быстрее других. Платформа GitLab CI написана на Ruby и Go. Основные ее возможности выпускаются под лицензией MIT с открытым исходным кодом, а остальные функции — под проприетарной лицензией.

Задачи в GitLab CI могут выполняться последовательно, параллельно либо на основе созданного нами конвейера с заданным порядком выполнения. Командные сценарии сборки можно программировать на любом языке. Вся важная информация о прогрессе отображается на одной панели. В GitLab CI есть прямая интеграция с GitLab Workflow и API для лучшего совмещения продуктов.

Посмотрите на пример из нашей практики, который наглядно показывает преимущества GitLab CI.

К нам обратился крупный заказчик из сферы продаж. В компании работало 5 команд разработки в 15 средах и 40 репозиториях. Разработка была беспорядочной, процесс деплоя — непрозрачный: было неизвестно, кто и когда выложил новую версию кода в продуктовое окружение. Однажды после очередного инкогнито-деплоя перестал работать сервис компании с 10 миллионами пользователей. Проблема длилась около двух часов — это привело к существенным убыткам бизнеса. Мы исправили проблему, но для ее предотвращения в будущем нужно было упорядочить работу команд и построить в компании процесс CI/CD.

Наши инженеры настроили работу в Git через альтернативную модель ветвления GitFlow, которая хорошо подходила в данном случае. Ветвление — основное понятие в Git, которое означает возможность отклонения от основной линии разработки и продолжения работы без вмешательства в основную линию. Ветвление позволяет управлять рабочим процессом (непрерывной поставки), в котором различные улучшения кода реализуются параллельно, но не с одинаковой степенью «готовности». В подходе GitFlow, который мы применили, используются в основном функциональные и несколько основных веток.

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

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

Главный звонок, что пора переходить на непрерывную интеграцию: ваши сроки тестирования значительно превышают сроки разработки.

Другие яркие показатели:

• неизвестно, кто именно и что зарелизил
  
• непонятно, когда должен быть релиз
• не видно, готов ли функционал
• не видно, покрыт ли функционал различными тестам

Хорошо, допустим некоторые или все пункты из этого чек-листа у вас совпали и вы определились, что будете использовать инструменты, которые соединяют непрерывную интеграцию с непрерывной поставкой. Как начать это делать?

Основные этапы внедрения непрерывной разработки/интеграции сводятся к следующему:

1. Привлечь всех заинтересованных специалистов еще перед первым этапом проекта. Практика принятия основных решений с учетом мнения всех экспертов позволяет снижать технический долг.
   
2. Подобрать такую систему CI/CD, которая позволит сделать процессы сборки, тестирования и поставки новых функций тривиальной задачей. Это повысит способность компании гибко реагировать на изменения.
   
3. Разработать методологию внедрения.
   
4. Описать инфраструктуру кодом.
   
5. Собрать комплект тестов и определить набор сред для тестирования кода и выкладки.
   
6. Настроить пайплайн.
   
7. Отслеживать и улучшать параметры стабильности циклов «сборка — тестирование — поставка» и в целом успешности работы CI/CD.
   
   

Отметим, что внедрять CI/CD в разработку или оптимизировать существующий процесс с помощью автоматизированных средств GitLab довольно непросто. Да, GitLab CI — открытое ПО и можно попробовать внедрить его самостоятельно. Однако здесь важен опыт разработки конкретной методологии внедрения. Методология должна быть разработана с обязательным учетом особенностей конкретного процесса. Само по себе ПО не имеет ценности, поскольку для его эффективного использования требуется как минимум уметь описать инфраструктуру кодом (например, с помощью Ansible), а также грамотно подобрать инструменты и среды для тестирования и выкладки. Более того, важно уметь сделать весь процесс внедрения технологии прозрачным и упорядоченным. Как правило, это могут осуществить только опытные DevOps-инженеры, которые давно работают на стыке разных технологий.

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

Методология непрерывной интеграции позволяет наладить целостный, автоматизированный способ сборки, упаковки и тестирования приложений. Целостность в процессе интеграции дает разработчикам возможность изменять код чаще — это улучшает совместную работу команд, а также качество приложения. Непрерывная доставка, идущая сразу за непрерывной интеграцией, проверяет загруженный код на разных окружениях и поставляет приложение на выбранное инфраструктурное окружение в автоматическом режиме. Это снижает процент ошибок за счет исключения из процесса человеческого фактора.

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