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