Библиотека сайта rus-linux.net
Непрерывная интеграция
Глава 9 из книги "Архитектура приложений с открытым исходным кодом", том 1.
Оригинал: Continuous Integration
Автор: C. Titus Brown, Rosangela Canino-Koning
Перевод: А.Панин
9.1. Многообразие систем непрерывной интеграции
В среде архитектур систем непрерывной интеграции прослеживается доминирование двух противоположных моделей: архитектур ведущих/ведомых серверов, в которых центральный сервер осуществляет управление и контролирует работу удаленных серверов для сборки; а также архитектур серверов обработки отчетов, в которых центральный сервер обрабатывает отчеты о сборке, отправленные клиентами. Все системы непрерывной интеграции, о существовании которых нам известно, выбрали некоторую комбинацию возможностей, присущих этим двум архитектурам.
Наш пример централизованной архитектуры, система Buildbot, состоит из двух частей: центрального сервера, также называемого buildmaster и предназначенного для планирования и координации процесса сборки программного обеспечения одним или большим количеством подключенных клиентов; а также клиентов, называемых buildslaves и непосредственно выполняющих сборку. Центральный сервер (buildmaster) является центральной точкой для подключения и хранит информацию о том, какие клиенты должны выполнять команды и в какой последовательности. Клиенты (buildslaves) соединяются с центральным сервером и получают подробные инструкции. Процесс настройки клиента заключается в установке программного обеспечения, идентификации центрального сервера, а также вводе данных для соединения с центральным сервером. Процессы сборки программного обеспечения планируются центральным сервером, а их вывод передается от клиентов центральному серверу и хранится на нем с целью последующего просмотра с помощью веб-интерфейса, а также отправки с помощью других систем отчетов и уведомлений.
На другом крае спектра архитектур находится система CDash, используемая системами виртуализации Visualization Toolkit (VTK)/Insight Toolkit (ITK) от компании Kitware, Inc. На самом деле, система CDash представлена сервером обработки отчетов, спроектированным для хранения и вывода информации, полученной от клиентских компьютеров, выполняющих операции с использованием систем CMake и CTest. При использовании системы CDash клиенты инициируют ряд процессов сборки и тестирования, записывают результаты сборки и тестирования, после чего соединяются с сервером CDash с целью сохранения с помощью него отчета.
Наконец, третья система, Jenkins (известная как Hudson до момента смены названия в 2011 году) может функционировать в двух режимах. В случае использования системы Jenkins, сборка с последующей отправкой отчетов центральному серверу может быть либо инициирована независимо; либо серверы могут исполнять команды центрального сервера Jenkins, который впоследствии будет планировать и управлять ходом процессов сборок.
Централизованная и децентрализованная модели имеют некоторые сходные возможности, и, как мы видим на примере системы Jenkins, эти модели могут сосуществовать в рамках одной реализации. Однако, системы Buildbot и CDash значительно отличаются друг от друга: помимо сходных функций сборки программного обеспечения и создания отчетов о сборке, все остальные аспекты их архитектуры кардинально отличаются. Почему?
Кроме того, в какой степени выбор архитектуры обуславливает простоту или сложность реализации определенных возможностей? Являются ли некоторые возможности следствием использования централизованной модели? И насколько расширяемы возможности существующих реализаций - могут ли они быть без сложностей модифицированы с целью поддержки новых механизмов работы с отчетами, подвергаться масштабированию для работы с множеством пакетов или выполнять операции сборки и тестирования программных продуктов в облачном окружении?
Продолжение статьи: Какие функции выполняются программным обеспечением непрерывной интеграции.