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

Основные функции системы непрерывной интеграции достаточно просты: сборка программного обеспечения, выполнение тестирования и отправка отчета о результатах. Сборка, тестирование и создание отчетов могут осуществляться с помощью сценария, выполнение которого запланировано в форме задачи cron: данный сценарий должен проверить наличие новой копии исходного кода в системе управления версиями (VCS), выполнить сборку исходного кода, после чего выполнить тестирование. Вывод должен быть записан в файл и либо храниться в установленном месте, либо отправляться с помощью электронной почты в случае неполадок. Этот процесс достаточно просто реализуем: в UNIX, например, весь этот процесс для большинства пакетов Python может быть реализован с помощью семистрочного сценария:

cd /tmp && \
svn checkout http://some.project.url && \
cd project_directory && \
python setup.py build && \
python setup.py test || \
echo build failed | sendmail notification@project.domain
cd /tmp && rm -fr project_directory

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

• Проверка и обновление исходного кода: При работе с проектами большого размера создание новой копии исходного кода может быть связано с затратами пропускной способности сети и времени. Обычно системы непрерывной интеграции вместо этого обновляют существующую рабочую копию исходного кода, сталкиваясь при этом только с обработкой изменений со времени предыдущего обновления. В обмен на эту экономию ресурсов, система должна заботиться об обновлении рабочей копии исходного кода и поддерживать ее в актуальном состоянии, что обычно подразумевает хотя бы минимальную интеграцию с системой контроля версий.
• Абстрактные рецепты сборки: Рецепт настройки/сборки/тестирования должен быть разработан для использования совместно с интересующим программным обеспечением. Команды низшего уровня обычно различны для различных операционных систем, т.е. для Mac OS X, Windows и UNIX, а это означает, что либо должны разрабатываться специализированные рецепты (описывающие потенциальные ошибки или несоответствия актуальному окружению сборки), либо в подсистеме настройки системы непрерывной интеграции должен быть создан некоторый подходящий уровень абстракции для рецептов.
• Хранение результатов обновления исходного кода/сборки/тестирования: Хранение подробностей выполнения процессов обновления исходного кода (списка обновленных файлов, версии кода), сборки (сообщений с предупреждениями и ошибками) и тестирования (степени охвата исходного кода, производительности, степени использования памяти) для последующего анализа может оказаться желательным. Эти подробности могут быть использованы для ответов на вопросы, возникающие при тестировании программного обеспечения для различных архитектур (изменилась ли в значительной степени производительность программного обеспечения для какой-либо архитектуры после последнего обновления?) или в различные периоды времени (изменилась ли значительно степень охвата исходного кода в течение последнего месяца?) Как и в случае рецептов сборки, механизмы и типы данных, используемые на этом этапе, обычно специфичны для платформы или системы сборки.
• Выпуск пакетов: В результате сборки могут формироваться бинарные пакеты или другие продукты, которые должны быть доступны извне. Например, разработчики, не имеющие прямого доступа к машине для сборки, могут изъявить желание участвовать в тестировании последней сборки программного обеспечения для определенной архитектуры; для этого система непрерывной интеграции должна иметь возможность передать собранные программные продукты в центральный репозиторий.
• Сборки для множества архитектур: Так как одной из задач непрерывной интеграции является сборка программного обеспечения для множества архитектур с целью тестирования кроссплатформенных функций, системам непрерывной интеграции может потребоваться отслеживать архитектуры каждой машины для сборки и связывать сборку и ее результаты с каждым клиентом.
• Управление ресурсами: Если этап сборки требователен к ресурсам, системе непрерывной интеграции может потребоваться использовать условия при сборке. Например, процесс сборки может ожидать отсутствия других процессов сборки или пользователей в системе или задерживаться до момента достижения определенных показателей загрузки центрального процессора и использования оперативной памяти.
• Координация внешних ресурсов: Процесс тестирования интеграции может зависеть от таких нелокальных ресурсов, как дополнительная база данных или удаленный веб-сервис. Таким образом, система непрерывной интеграции должна координировать работу процессов сборки на множестве машин для организации доступа к этим ресурсам.
• Отчеты о выполнении действий: При длительных процессах сборки регулярная отправка отчетов может быть также важна. Если пользователя в первую очередь интересуют результаты выполнения процесса сборки и тестирования в течение первых 30 минут вместо 5 часов, то принудительное ожидание завершения этого процесса для просмотра результатов приведет к потере времени.