Библиотека сайта rus-linux.net
Непрерывная интеграция
Глава 9 из книги "Архитектура приложений с открытым исходным кодом", том 1.
Оригинал: Continuous Integration
Автор: C. Titus Brown, Rosangela Canino-Koning
Перевод: А.Панин
9.2. Архитектуры
В ходе разработки проектов Buildbot и CDash были выбраны диаметрально противоположные архитектуры, при этом были реализованы перекрывающиеся, но разделенные наборы возможностей. Ниже мы опишем эти наборы возможностей и обсудим то, насколько эти возможности проще или сложнее реализовать в зависимости от выбранной архитектуры.
9.2.1. Модель реализации: Buildbot
Рисунок 9.2. Архитектура системы Buildbot
Система Buildbot использует архитектуру ведущих/ведомых серверов, которая предусматривает единственный центральный сервер и множество управляемых им серверов для сборки. Удаленное исполнение команд осуществляется в полном соответствии со сценарием центрального сервера в реальном времени: центральный сервер отправляет команды для исполнения каждой из удаленных систем, которые начинают выполняться сразу же после завершения выполнения предыдущих команд. Планирование выполнения команд и запросы сборки не только координируются, но и полностью контролируются центральным сервером. Встроенной абстракции для рецептов сборки не существует, за исключением простейшей интеграции с системой контроля версий ("наш код в этом репозитории") и разделением команд для работы с директорией для сборки и команд для работы в директории для сборки. Специфические для операционных систем команды обычно задаются на этапе настройки.
Система Buildbot поддерживает постоянное соединение с каждой системой для сборки и осуществляет управление и координацию исполнения задач этими системами. Управление удаленными машинами посредством постоянного соединения добавляло сложностей при практической реализации и в течение длительного периода времени являлось источником ошибок. Длительная поддержка надежно функционирующих сетевых соединений не так проста и тестирование приложений, взаимодействующих с локальным графическим интерфейсом посредством сети, требует больших затрат труда. Особенно сложно работать с предупреждениям от операционной системы, выводимыми в окнах сообщений. Однако, это постоянное соединение упрощает процессы координации и управления ресурсами, так как для выполнения задач ведомые машины находятся в полном распоряжении ведущей машины.
Тип непосредственного управления, применяемый в модели реализации Buildbot, делает централизованную координацию ресурсов для сборки достаточно простой. В системе Buildbot предусмотрены блокировки для центрального и ведомых серверов на центральном сервере, поэтому могут координироваться как глобальные сборки в рамках всей системы, так и локальные сборки в рамках ресурсов отдельных машин. Это обстоятельство делает систему Buildbot в большей степени пригодной для больших систем, на которых проводится тесты системной интеграции, т.е. тесты, в ходе которых осуществляется взаимодействие с базами данных или другими связанными с затратами ресурсов программными компонентами.
Следует учесть тот факт, что централизованная конфигурация обуславливает проблемы в случае использования распределенной модели. Каждый новый сервер для сборки должен быть явно задан при настройке центрального сервера, что делает невозможным динамическое подключение к центральному серверу новых серверов для сборки и их последующую эксплуатацию. Более того, так как каждый сервер для сборки находится под полным управлением центрального сервера, серверы сборки уязвимы для умышленных и случайных операций задания некорректных настроек: центральный сервер буквально осуществляет тотальный контроль клиента, контролируя также ограничения безопасности операционной системы клиента.
Одним из ограничений возможностей системы Buildbot является невозможность реализации простого способа возврата собранных программных продуктов на центральный сервер. Например, статистика охвата кода и бинарные пакеты хранятся на удаленном сервере для сборки, при этом не существует API для передачи их на центральный сервер с целью хранения и последующего распространения. Причины отсутствия данной возможности непонятны. Возможно, это последствие использования ограниченного набора распространяемых в составе Buildbot командных абстракций, которые главным образом направлены на удаленное выполнение команд серверами для сборки. Также, возможно это вызвано решением использовать соединение между центральным сервером и серверами сборки как систему контроля, а не механизм удаленного вызова процедур.
Другим последствием использования модели ведущих/ведомых серверов и ее ограниченного канала для взаимодействия является невозможность отправки отчетов о загрузке системы центральному серверу от ведомых серверов, поэтому центральный сервер не может избегать больших нагрузок на системы сборки.
Внешние уведомления о использовании центрального процессора в результате сборки в полной мере обрабатываются центральным сервером и новые службы уведомлений должны быть реализованы именно на стороне центрального сервера. Аналогично, новые запросы сборки должны отправляться напрямую центральному серверу.
Продолжение статьи: Модель реализации: CDash.