Гибкая разработка программного обеспечения не может быть идеальной без эффективного процесса непрерывной интеграции. CI — это процесс непрерывного анализа, создания, тестирования и развертывания программного обеспечения. Непрерывная интеграция проверяет внутреннее качество кода и тестирует бизнес-логику продукта перед его выпуском в производство.

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

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

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

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

1. Примитивное автоматизированное тестирование

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

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

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

С помощью Endtest вы можете создавать и запускать автоматизированные тесты в кросс-браузерной облачной инфраструктуре и лаборатории мобильных устройств. И все это можно сделать, не написав ни строчки кода, а это значит, что даже ваш Product Owner может быстро написать несколько тестов.

Ford, MasterCard, KLM, Qatar Airways, Dell, Under Armour — это лишь некоторые из известных компаний, которые полагаются на Endtest.

Есть и другие альтернативы, вы можете написать свои собственные тесты и запустить их с помощью BrowserStack или SauceLabs, но это дороже и вы не получите того же стабильность.

2. Неправильный выбор сервера CI

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

Дженкинс — один из популярных CI-серверов, и люди склонны использовать его вслепую. Нам пришлось настроить наш проект для работы с Jenkins, и команде пришлось пойти на компромисс с услугами, которые предлагает Jenkins. Теперь эта ситуация изменилась, и на рынке появились различные многообещающие сервисы CI. Глядя на широкий спектр CI-серверов на рынке, сложно выбрать тот, который соответствует потребностям нашего проекта.

Процесс настройки CI-сервера требует времени и денег. Если вы выберете CI-сервер, не проведя никаких исследований, и он не сработает для команды, то все усилия, которые вы приложили для получения CI-сервера, будут напрасными. Распространенная ошибка, которую допускает руководство, заключается в том, что выбор общего сервера или службы CI для всех таких платформ не работает достаточно хорошо. Представьте, что у вашего приложения есть веб-сайт, приложение для iOS и приложение для Android; поиск общего решения может не сработать. Мы должны быть очень осторожны при выборе нашего сервера CI.

Возможные решения

  • Тщательно изучите рынок и оцените варианты пилотных проектов. Slant уже оценил основные серверы непрерывной интеграции с плюсами и минусами каждого из них.
  • При оценке серверов CI обратите внимание на такие функции, как поддержка конвейера, конвейер как код, поддержка контейнера Docker, поддержка платформы, простота использования, доступность и т. д.
  • Не пытайтесь найти универсальное решение для всех платформ, чтобы снизить затраты. Каждая платформа имеет различные технические требования и задачи.
  • Обсудите это с командой и спросите о прошлом опыте, чтобы нам не нужно было снова обучать инженеров.

3. Инженеры-любители КИ

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

В последнее время компании переносят инфраструктуру в облако, поэтому необходимо изучить навыки DevOps, т. е. облачные сервисы, такие как AWS, Azure и Heroku; инструменты подготовки, такие как bash, Ansible и Chef; и контейнерные сервисы, такие как Docker и Kubernetes. Самое главное — это знание одного из языков сценариев, то есть Bash, Ruby или Python.

Это не значит, что вы должны изучать все на свете, но вы должны изучать все для своей платформы. Предположим, что инженер занимается разработкой приложения для iOS. Инженер должен знать такие инструменты, как Cocoapods, Carthage и Swift Package Manager для управления зависимостями.

Кроме того, инструменты автоматизации сборки, такие как Fastlane, Rake и Make, имеют сильное влияние на родные инструменты командной строки Apple. Инженер должен знать о последних инструментах, связанных с соответствующей платформой.

На рынке есть разные типы инженеров; некоторые из них умеют писать код на родном языке (например, Java, Objective-C и Swift) и хорошо разбираются в DevOps и инструментах автоматизации сборки. Некоторые инженеры просто пишут код в среде IDE (например, Eclipse, IntelliJ и Xcode), не способной выполнять команды с терминала. Некоторые инженеры лучше разбираются в инструментах автоматизации сборки, но не так хороши в написании кода на родном языке.

Любители CI — это те, кто не может выйти из IDE и не умеет использовать инструменты командной строки (скрипты). Они предпочитают инструменты с графическим интерфейсом всему, чем командную строку или сценарии. Однако сервер CI не имеет графического интерфейса для взаимодействия, поэтому все должно быть написано в сценарии.

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

Возможные решения

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

4. Трубопровод не закодирован

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

Возможное решение

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

5. Серверные машины низкого качества сборки

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

Возможные решения

  • Получите быстрый и надежный сервер для непрерывной интеграции; избегайте дешевых серверов.
  • Никогда не оставляйте сервер CI включенным WiFi.
  • Никогда не устанавливайте ненужное программное обеспечение на сервер CI.
  • Разумно делитесь сервером CI, назначая определенные задания.
  • Никогда не устанавливайте никакое программное обеспечение вручную.
  • Избегайте предоставления графического интерфейса для доступа к машинам. Доступа по SSH должно быть достаточно.
  • Настройте методы CI с командой и применяйте их строго внутри команды.
  • Обучайте руководителей проектов методам CI.

Вывод

Внедрить методы непрерывной интеграции в Agile-команде сложно, но соблюдение некоторых строгих правил и избежание распространенных ошибок могут сделать процесс CI более эффективным. Каков ваш опыт работы с CI-серверами? Считаете ли вы, что ваши методы CI работают хорошо? Взвесьте с комментарием ниже!