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