Рейтинг@Mail.ru
[Войти] [Зарегистрироваться]

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

UnixForum
Беспроводные выключатели nooLite купить дешевый 
компьютер родом из Dhgate.com

Lines Club

Ищем достойных соперников.

Библиотека сайта или "Мой Linux Documentation Project"

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

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

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

9.2.2. Модель реализации: CDash

Архитектура CDash
Рисунок 9.3: Архитектура CDash

В отличие от системы Buildbot, система CDash реализует модель сервера обработки отчетов. В этой модели сервер CDash выступает в качестве центрального репозитория для хранения информации о осуществленных удаленно сборках вместе с сопутствующими отчетами о неполадках при сборке и тестировании, результатах анализа охвата кода и использования памяти. Сборки осуществляются на удаленных клиентах по их собственному графику, после чего отправляются отчеты о сборке в формате XML. Отчеты о сборке могут отправляться как "официальными" клиентами, так и сторонними разработчиками или пользователями, выполняющими процесс сборки на своих машинах.

Реализация этой простой модели стала возможной благодаря тесной концептуальной интеграции между системой CDash и другими элементами инфраструктуры сборки программных компонентов компании Kitware: Cmake, системы настройки и сборки, CTest, системы тестирования и CPack, системы создания пакетов. Это программное обеспечение создает механизм, с помощью которого рецепты сборки, тестирования и создания пакетов могут быть реализованы на достаточно высоком уровне абстракции независимо от используемой операционной системы.

Процесс работы системы CDash с инициированием действий на стороне клиентов упрощает множество аспектов реализации процесса непрерывной интеграции на стороне клиента. Решение о начале сборки принимается клиентами, поэтому условия на стороне клиентов (время дня, высокая нагрузка, и.т.д.) могут быть приняты во внимание перед началом сборки. Клиенты могут появляться и исчезать по собственному желанию, что сводит на нет сложности проведения сторонних сборок и "сборок в облаке". Собранные программные продукты могут быть отправлены на центральный сервер с помощью простого механизма загрузки.

Однако, результатом использования модели обработки отчетов в CDash стало отсутствие многих полезных функций из системы Buildbot. Отсутствует централизованная координация ресурсов, причем эта функция не может быть просто реализована в распределенном окружении с непроверенными или ненадежными клиентами. Механизм отчетов о выполнении операций также не реализован: для реализации сервер должен позволять осуществлять последовательное обновление состояния сборки. И, конечно же, не существует способа для глобального запроса сборки с гарантией его выполнения анонимными клиентами в ответ на запрос - клиенты должны рассматриваться как ненадежные.

Не так давно в систему CDash были добавлены функции для работы системы сборки в облаке "@Home", в которой клиенты предоставляют ресурсы для сборки серверу CDash. Клиенты опрашивают сервер на наличие запросов на сборку, выполняют сборку в соответствии с запросами и возвращают результаты серверу. В текущей реализации (от октября 2010 года) сборки должны быть инициированы вручную на стороне сервера и клиенты должны быть соединены с сервером для предоставления своих услуг по сборке. Однако, эту модель достаточно просто усовершенствовать до более обобщенной модели планируемых сборок, в которой сборки запрашиваются автоматически сервером в случае доступности подходящего клиента. Система "@Home" по концепции очень похожа на систему Pony-Build, которая будет описана позднее.


Продолжение статьи: Модель реализации: Jenkins.


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

Комментарии отсутствуют