Непрерывная поставка программного обеспечения в эпоху цифровых технологий зависит от конвейеров CI/CD, которые позволяют инженерным командам быстро разрабатывать, тестировать и развертывать код, сохраняя при этом высокую удобство использования и согласованность между средами. Однако конвейеры CI/CD — когда системы начинают с небольших масштабов и со временем становятся сложными — сами по себе могут стать источником проблем. Конвейеры, настроенные для работы с небольшими проектами, с трудом масштабируются при увеличении количества репозиториев, расширении наборов тестов и росте команд разработчиков. Медленные циклы обратной связи, увеличение затрат на инфраструктуру и снижение производительности разработчиков — вот некоторые из побочных эффектов неэффективного проектирования конвейеров.
Ниже приведены 10 типичных ошибок при построении конвейеров CI/CD, с которыми вы часто будете сталкиваться в ходе повседневной работы с конвейерами CI/CD в своей среде; они основаны на распространенных паттернах, характерных для многих инженерных сообществ.
Рассматривать конвейеры CI/CD как «настроил и забыл»
Некоторые команды настраивают конвейер CI/CD в начале проекта, а затем практически не возвращаются к нему. Конвейер приложения растет по мере накопления компонентов без какого-либо плана! Наборы тестов становятся больше, добавляются новые этапы сборки, а репозитории разрастаются. Однако без регулярного пересмотра конвейеры постепенно становятся все более медленными и сложными.
Частый мониторинг для оценки производительности конвейера должен входить в обязанности команды. Конвейеры CI/CD следует пересматривать и обновлять вместе с базовым программным обеспечением.
Один большой монолитный конвейер
Еще одной распространенной ошибкой является создание единого конвейера, отвечающего за весь процесс проверки и развертывания. Такие конвейеры часто объединяют в себе: линтинг, тестирование, упаковку, сканирование на безопасность и развертывание. Однако монолитные конвейеры работают медленно и их невозможно эффективно поддерживать при масштабировании.
Вместо этого масштабируемым подходом является использование отдельных конвейеров, предназначенных для разных целей:
- Конвейеры быстрой валидации для пулл-реквестов
- Расширенные тестовые конвейеры для всех слияний
- Конвейеры развертывания релизов
Такая структура позволяет разработчикам получать оперативную обратную связь и при этом обеспечивать тщательную валидацию перед выпуском в производственную среду.
Невозможность мониторинга производительности конвейеров
Инженеры уделяют много внимания мониторингу производственных систем; однако конвейеры CI/CD не всегда могут обеспечить такую же степень прозрачности. Когда конвейеры работают медленно из-за частых остановок или из-за ненадёжности, команде может быть сложно, а то и вовсе невозможно, ответить на такие вопросы, как:
- На каком этапе конвейера уходит больше всего времени?
- Какие репозитории запускают наибольшее количество сборок?
- Где чаще всего происходят сбои?
Добавление метрик, информационных панелей и журналов для обеспечения наблюдаемости конвейеров позволяет командам выявлять узкие места в производительности и повышать стабильность конвейеров.
Управление обширными зависимостями является причиной длительного времени сборки
В крупных проектах могут возникать значительные задержки, если в конвейерах происходит многократная загрузка зависимостей из внешних реестров.
К методам, повышающим производительность работы с зависимостями, относятся: кэширование зависимостей, кэширование слоёв Docker, повторное использование артефактов между этапами конвейера. Даже небольшой шаг в направлении кэширования может значительно сократить время сборки.
Сбалансированное тестирование — зачастую лучший вариант
Слишком много тестирования или слишком мало тестов? Стратегия тестирования напрямую влияет на производительность конвейера CI/CD. Некоторые команды запускают весь набор тестов при каждом коммите, что приводит к длительным циклам обратной связи. Другие не так хорошо справляются с тестированием в рамках CI и, даже имея CI, по-прежнему вынуждены проводить столько же ручной проверки.
Рекомендуется использовать следующий подход:
- Юнит-тесты при каждой фиксации
- Интеграционные тесты, выполняемые при слиянии
- Полные регрессионные тесты перед развертыванием релизов
Благодаря такому подходу разработчики могут получать быструю обратную связь, сохраняя при этом качество программного обеспечения.
Игнорирование параллельного выполнения
Многие конвейеры выполняют задачи именно в таком порядке, поскольку именно так был настроен конвейер по умолчанию при его создании.
Современные платформы CI/CD поддерживают параллельное выполнение таких задач, как запуск наборов тестов, сборка микросервисов и выполнение проверок валидации. Благодаря параллелизму команды могут значительно сократить общее время выполнения конвейера и ускорить рабочие процессы разработки.
Создание несогласованных сред сборок
Несогласованность сред чаще всего приводит к сбоям в конвейере CI/CD. Сборка локально в одной среде и CI в другой приводит к неожиданным сбоям, которых можно было бы избежать. Это происходит, когда разработчики запускают сборку локально в одной среде, а системы CI используют другую, и в результате обнаруживают неожиданные сбои. Как правило, это приводит к типичной ситуации, когда код работает в локальной среде, но выдает ошибку в конвейере.
Контейнерная среда или воспроизводимая среда сборки помогут обеспечить согласованность между рабочей машиной разработчика и системами CI.
Необходимо улучшить отказоустойчивость конвейеров
Сборки могут время от времени прерываться из-за нестабильности сети, ненадёжных тестов или временных проблем с зависимостями. Без отказоустойчивых конвейеров существует риск, что сбои будут происходить слишком часто, чтобы их можно было предотвратить; вместо этого разработчики будут вынуждены лишь перезапускать сборки.
В таких ситуациях могут помочь алгоритмы повторных попыток при временных сбоях, изоляция нестабильных тестов и чёткие механизмы отчётов об ошибках. Повышенная отказоустойчивость конвейера сокращает количество ненужных прерываний в существующем рабочем процессе разработки.
Неэффективные методы управления секретными данными
На ранних этапах внедрения CI/CD вопросам безопасности обычно уделяется недостаточное внимание. Учетные данные (например, токены API, ключи доступа к сервисам или пароли к базам данных) могут храниться непосредственно в конфигурационных файлах или переменных среды без надлежащих мер защиты. Когда конвейеры CI/CD используют секретные данные совместно со многими сервисами, включая компоненты инфраструктуры, безопасное управление секретными данными может приобретать критическое значение.
Существенно снизить риски безопасности можно за счет внедрения инструментов управления секретными данными и ротации паролей по требованию.
Пренебрежение интересами разработчиков
Конвейеры CI/CD разрабатываются для поддержки разработчиков и ускорения выпуска программного обеспечения, чтобы быстрее вывести его на рынок. Когда конвейеры работают медленно, ведут себя непредсказуемо или их сложно отлаживать, это не просто снижает производительность, а полностью её останавливает.
Хорошие конвейеры обеспечивают следующее: быстрые циклы обратной связи, чёткие сообщения об ошибках и предсказуемое выполнение. Когда конвейеры работают хорошо, разработчикам редко приходится о них задумываться.
Заключительные мысли
Конвейеры CI/CD часто рассматриваются как вспомогательная инфраструктура, но они имеют решающее значение для современной доставки программного обеспечения. Конвейеры должны развиваться вместе со сложностью систем. Анализ архитектуры, производительности и надёжности конвейеров может привести к значительному повышению производительности инженерных работ и стабильности системы. Даже такие постепенные улучшения, как эффективное кэширование, более продуманные стратегии кэширования, чёткое разграничение этапов конвейера и улучшенная наблюдаемость, могут принести долгосрочные выгоды.
Читайте также
Подписывайтесь на наш канал в Телеграм
⚡ Подписаться