Рейтинг@Mail.ru

Наши друзья и партнеры

UnixForum
купить дешевый 
компьютер родом из Dhgate.com




Библиотека сайта rus-linux.net

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

Глава 9 из книги "Архитектура приложений с открытым исходным кодом", том 1.

Оригинал: Continuous Integration
Автор: C. Titus Brown, Rosangela Canino-Koning
Перевод: А.Панин

9.1.1. Какие функции выполняются программным обеспечением непрерывной интеграции

Основные функции системы непрерывной интеграции достаточно просты: сборка программного обеспечения, выполнение тестирования и отправка отчета о результатах. Сборка, тестирование и создание отчетов могут осуществляться с помощью сценария, выполнение которого запланировано в форме задачи 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

На Рисунке 9.1 незаштрихованные прямоугольники представляют отдельные подсистемы и функции в рамках системы. Стрелки указывают направления информационных потоков между различными компонентами. Облако представляет потенциальную возможность удаленного выполнения процессов сборки. Заштрихованные прямоугольники представляют потенциальные объединения подсистем; например, мониторинг процесса сборки включает в себя мониторинг самого процесса сборки, а также мониторинг состояния системы (загрузки центрального процессора, нагрузки вследствие операций ввода/вывода, использования оперативной памяти, и.т.д.)

Внутреннее устройство системы непрерывной интеграции
Рисунок 9.1: Внутреннее устройство системы непрерывной интеграции

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

Высокоуровневое представление этих возможных компонентов системы непрерывной интеграции показано на Рисунке 9.1. Программное обеспечение непрерывной интеграции обычно реализует некоторое подмножество этих компонентов.


Продолжение статьи: Внешние взаимодействия.

Если вам понравилась статья, поделитесь ею с друзьями: