Введение в непрерывную интеграцию

Интеграционные проблемы в разработке ПО уже давно стали притчей во языцех. Вася делает модуль В, Сергей делает модуль С, оба модуля протестированы, найденное исправлено, вероятность нахождения ненайденного неприятного минимальна. Казалось бы, все хорошо, но вот незадача: модули эти должны работать не по одиночке, а вместе. Почти всю итерацию Вася и Сергей работают локально, не совмещая написанные модули. При попытке соединения за неделю до поставки модули начинают вести себя неадекватно и время интеграции увеличивается значительно. Поставка переносится на неделю, Вася винит Сергея, Сергей винит Васю. Проблема подкралась "внезапно". Недавно я где-то увидел хороший принцип: "то, что делать неприятно, надо делать чаще". Он отлично ложится на разработку ПО, в частности, на его интеграцию. Подход, при котором интеграция проекта осуществляется настолько часто, насколько это возможно, называется "непрерывной интеграцией" (Continuous Integration*).

Общие понятия

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

1. Повышение уверенности – после сотни успешных построений легче быть уверенным в успешности 101-го построения.
2. Экономия времени за счет автоматизации повторяемых действий – для успешных регулярных построений проекта обычно требуется автоматизировать все рутинные задачи. Более того, автоматизация рутины позволяет гарантировать одинаковое выполнение необходимых шагов, устраняя риск появления непонятных дефектов при развертывании.
3. Развертываемость программного обеспечения – использование подхода непрерывной интеграции позволяет осуществить полное построение проекта с развертыванием, если иметь на входе папку с исходниками и нажать лишь одну кнопку. В случае необходимости поставка пройдет так быстро, как это возможно.

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

Непрерывная интеграция баз данных

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

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

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

Непрерывная инспекция

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

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

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

Итого

Мы кратко рассмотрели понятие "непрерывной интеграции" и ее основных составных частей: непрерывной интеграции баз данных, непрерывного тестирования и непрерывного развертывания. Эти техники позволяют снизить риски поздней интеграции, вовремя реагировать на появившиеся дефекты, повысить уверенность в качестве продукта. Поскольку непрерывная интеграция сейчас используется почти везде, было бы интересно услышать про случаи, когда ее применение затруднено или бессмысленно. Может кто-нибудь поделиться подобными? * Да, я знаю, что "Continuous" это никак не "Непрерывный" :)

Место солидарности беларусского ИТ-комьюнити

Далучайся!