Непрерывная интеграция

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

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

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

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

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

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

Это решительно не быстро.

  

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

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

Две практики удерживают нас от этой ситуации:

Непрерывная сборка: Сборка проекта, как только внесены изменения. В идеале, дельта между каждой сборкой - это один набор изменений.

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

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

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

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

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

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

Модульные тесты выполняются очень близко к основным компонентам в коде. Они являются первой линией обороны в обеспечении качества.

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

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

 

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

 

API тесты

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

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

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

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

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

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

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

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

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

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

Говоря о которых...

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

Сделайте вашу непрерывную интеграцию быстрой

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

Запуск автоматических тестов может быстро сложить и определить продолжительность сборки. Одна из стратегий - распараллеливать автоматические тесты на нескольких серверах или «агентах сборки», чтобы на сервере CI фактически выполнялось 2, 20 или даже 200 тестов одновременно.

Облачные технологии позволяют легко масштабировать ЦП в соответствии с потребностями вашей команды разработчиков по мере роста ваших наборов тестов. Но процессор не безграничен. Протестируйте каждую область кода полностью, но не избыточно. Избыточные тесты увеличивают длительность сборки (и тратят ресурсы процессора). Чем быстрее инженеры получают зеленый свет, тем быстрее они могут перейти к следующему пункту в списке необходимых требований (backlog).

Ветвление и CI: спичка, созданная на небесах!

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

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

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

По материалам Agile Coach "Continuous integration"