Закрыть

Непрерывная интеграция: разъяснения

Придайте гибкости своей команде, ускорив обратную связь. Ваша реальная скорость определяется скоростью ваших тестов.

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

Статьи о непрерывной интеграции

[ПРОДОЛЖЕНИЕ]

Что такое непрерывная интеграция?

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

Автоматизированное тестирование, непрерывная поставка и непрерывное развертывание

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

Автоматизированное тестирование

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

Непрерывная поставка

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

Непрерывное развертывание

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

Преимущества непрерывной интеграции

Вложения в непрерывную интеграцию возвращаются в виде быстрой обратной связи по изменениям в коде. Быстрой — значит появляющейся за считанные минуты. Команда, которая полагается прежде всего на ручное тестирование, может получить обратную связь через пару часов, но на деле исчерпывающая обратная связь по тестированию приходит через день (или несколько дней) после изменения кода. А к тому времени будет внесено еще больше изменений, что превращает устранение багов в археологическую экспедицию, когда разработчики копаются в нескольких уровнях кода в поисках первопричин проблемы.

Это происходит совсем не быстро.

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

Защитите качество своего продукта с помощью непрерывных сборок и автоматизации тестирования

Как часто, скачав последнюю версию исходного кода, нам приходится натыкаться на то, что он не компилируется или содержит серьезный баг? Какая уж тут эффективная работа!

От такой ситуации могут спасти два подхода.

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

Автоматизация тестирования: программная проверка ПО для обеспечения качества. Тесты могут инициировать действия в ПО из пользовательского интерфейса (подробнее об этом чуть позже) или на уровне сервисов бэкенда.

Эти два подхода — как масло и варенье на вашем бутерброде: по отдельности вкусно, вместе — просто восторг! Непрерывная интеграция объединяет непрерывную сборку с автоматизацией тестирования. В результате при каждой сборке оценивается и качество базы кода.

И запомните: для полной реализации потенциальных преимуществ команда должна быть достаточно дисциплинированной, чтобы приостанавливать разработку и незамедлительно приступать к устранению сбоев. Энергия, которую команда инвестирует в написание тестов и настройку автоматизации (помните, что это действительно инвестиции), будет потрачена напрасно, если сборки будут долго оставаться в нерабочем состоянии. Защита инвестиций в CI и защита качества базы кода — это одно и то же. 

Тестирование при CI: модульные тесты, тесты API и функциональные тесты

В ходе непрерывной интеграции выполняется два основных этапа. На первом этапе выполняется проверка компилируемости кода. (В случае интерпретируемых языков все элементы проекта на этом этапе просто собираются воедино.) Второй этап включает проверку того, что код работает надлежащим образом. Самый надежный способ такой проверки — серия автоматических тестов, оценивающих продукт на всех уровнях. 

Модульные тесты

Преимущества: просто написать, быстро выполняются, довольно точно моделируют архитектуру базы кода.

Недостатки: модульные тесты проверяют только основные компоненты программного обеспечения; они не воспроизводят пользовательские процессы, в которых часто применяется несколько совместно работающих компонентов.

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

Тесты API

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

Преимущества. Как правило, их несложно писать, и они быстро запускаются. Кроме того, можно просто моделировать взаимодействие приложений между собой.

Недостатки: на простых отрезках кода тесты API могут повторять отдельные модульные тесты.

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

Функциональные тесты

Функциональные тесты выполняются в отношении более крупных частей базы кода и моделируют пользовательские процессы. Например, при тестировании веб-приложений HTTPUnit и Selenium с целью проверки продукта взаимодействуют непосредственно с пользовательским интерфейсом.

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

Недостатки. Работают медленнее (по сравнению с модульными тестами). Иногда возможны ложноотрицательные результаты по причине задержки в сети или кратковременного простоя в какой-либо части технологического стека.

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

Кстати говоря...

Некоторые тестировщики считают автоматические тесты угрозой для своего существования. Это заблуждение, которое очень далеко от истины. Избавляясь от рутинных задач по тестированию, тестировщики могут тратить свое время на анализ рисков, планирование тестов, а также на развитие других навыков: например, на изучение программирования. 

Ускоряйте непрерывную интеграцию

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

Выполнение автоматических тестов может существенно усложнить и затянуть выполнение сборки. Одна из стратегий заключается в распараллеливании автоматических тестов на нескольких серверах, или «агентах сборки», чтобы на сервере непрерывной интеграции фактически выполнялось 2, 20 или даже 200 тестов одновременно. Облачные технологии позволяют по мере расширения наборов тестов без труда масштабировать ресурсы процессора в соответствии с потребностями команды разработки. Однако ресурсы процессора не бесконечны. Тестировать каждый участок кода нужно в полной мере, но без избыточности. Избыточные тесты чрезмерно увеличивают продолжительность сборки (и тратят ресурсы процессора впустую). Чем быстрее разработчики получают зеленый свет, тем быстрее они могут перейти к следующему пункту бэклога. 

Ветвление и непрерывная интеграция —это идеальное сочетание!

Многие команды избегают создавать новые ветки из-за мучительного процесса последующего слияния. Однако новые технологии контроля версий, такие как Git, упрощают как ветвление, так и слияние. Чтобы гарантировать, что основной поток кода («master» на языке Git) остается работоспособным, нужно обеспечивать одинаковый уровень непрерывной интеграции как во всех ветках разработки, так и в ветках стабильных версий. Когда сборка ветки завершается успешно, команда может спокойно выполнять ее слияние с основным потоком кода.

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

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

Дэн Радиган
Дэн Радиган

Методология Agile оказала на меня огромное влияние как в профессиональном, так и в личном плане. Я понял, что и в работе, и в жизни лучший подход — гибкий. Я интересуюсь технологиями, фотосъемкой и мотоциклами. До встречи в Twitter! @danradigan