Библиотека сайта rus-linux.net
Непрерывная интеграция
Глава 9 из книги "Архитектура приложений с открытым исходным кодом", том 1.
Оригинал: Continuous Integration
Автор: C. Titus Brown, Rosangela Canino-Koning
Перевод: А.Панин
9.3. Будущее систем непрерывной интеграции
- Независимый от языка программирования набор рецептов сборки: На данный момент каждая система непрерывной интеграции идет по пути повторного изобретения колеса, реализуя свой собственный язык указания параметров сборки, что довольно забавно, ведь существует небольшое количество часто используемых систем сборки программного обеспечения и, вероятно, еще меньшее количество систем его тестирования. Несмотря на это, каждая система непрерывной интеграции использует новый и отличный от остальных способ задания команд для сборки и тестирования, которые должны быть выполнены. Фактически это обстоятельство является одной из причин существования такого множества в основном аналогичных систем непрерывной интеграции: каждое сообщество использует свой язык и создает свою систему настройки, привязанную к своим системам для сборки и тестирования, и основывающуюся на одних и тех же наборах низкоуровневых возможностей. Следовательно, создание предметно-ориентированного языка с возможностью представления параметров, используемых множеством наиболее часто применяемых наборов инструментов для сборки и тестирования позволит сгладить различия между системами непрерывной интеграции в значительной степени.
- Применение стандартных форматов при формировании отчетов о сборке и тестировании: Не существует четкого соглашения насчет того, какую именно информацию и в каком формате должны предоставлять системы сборки и тестирования. В случае создания формата или стандарта системам непрерывной интеграции будет значительно легче предоставлять как подробную, так и краткую информацию о сборках. Протокол Test Anywhere, TAP (от сообщества разработчиков языка Perl) и формат вывода результатов тестирования JUnit XML (от сообщества разработчиков языка Java) являются двумя интересными вариантами, с помощью которых можно закодировать информацию о количестве проведенных тестов, удачных и неудачных тестах и охвату кода для каждого из файлов.
- Повышение уровня детализации и представления внутренних функций при создании отчетов: Кроме того, удобным решением является предоставление хорошо документированного набора точек вызова функций для взаимодействия с системами настройки, компиляции и тестирования. Это позволило бы создать API (вместо стандартного формата), который могли бы использовать все системы непрерывной интеграции для извлечения подробной информации о сборках.
9.3.1. Заключительные размышления
Описанные выше системы непрерывной интеграции реализуют возможности, соответствующие их архитектуре, в то время, как система с гибридной архитектурой Jenkins начала свое развитие с реализации архитектуры ведущего/ведомых серверов, в которую позднее были добавлены возможности, присущие архитектуре обработки отчетов со свободным объединением компонентов.
На основе этого наблюдения можно сделать вывод о том, что выбор архитектуры обуславливает функции системы. Конечно же, это не так. Скорее выбор архитектуры задает направление развития и реализации определенного набора функций. В ходе работы над системой Pony-Build мы были удивлены тем, настолько наш начальный выбор аналогичной системе CDash архитектуры обработки отчетов повлиял на будущие решения в области проектирования и реализации функций. Некоторые практические решения, такие, как уход от централизованной настройки и реализация подсистемы планирования в системе Pony-Build были приняты при учете наших условий эксплуатации данной системы: нам было необходимо обеспечить возможность динамического подключения удаленных клиентов для сборки, что сложно реализовать в случае использования системы Buildbot. Другие не реализованные нами в системе Pony-Build возможности, такие, как отчеты о состоянии сборки и централизованные блокировки ресурсов, были желательны, но очень сложны в реализации, для которой отсутствовали весомые аргументы.
Похожая логика может быть применена и к таким системам, как Buildbot, CDash и Jenkins. В каждом случае отсутствуют полезные возможности, вероятно, из-за несовместимости с выбранной архитектурой. Однако, после обсуждения с участниками сообществ Buildbot и CDash, а также чтения веб-сайта проекта Jenkins у нас сформировалось мнение о том, что необходимые функции были выбраны с самого начала, после чего началась разработка системы с использованием архитектуры, которая упрощает реализацию этих функций. Например, система CDash обслуживает сообщество с небольшим числом основных разработчиков, которые ведут разработку программного обеспечения, используя централизованную модель. Их главной задачей является поддержание работоспособности программного обеспечения на основных машинах, а вторичной - прием сообщений об ошибках от разбирающихся в технических тонкостях пользователей. В то же время, система Buildbot широко применяется в сложных окружениях с множеством клиентов, действия которых должны координироваться для доступа к разделяемым ресурсам. Более гибкий формат файлов настройки системы Buildbot с множеством параметров для планирования, изменения режима работы механизмов уведомлений и блокировок ресурсов подходит для этой цели лучше других. Наконец, система Jenkins нацелена на простоту использования и упрощение процесса непрерывной интеграции, используя для настройки графический интерфейс и параметры настройки для работы на локальном сервере.
Социальная составляющая процесса разработки программного обеспечения с открытым исходным кодом является другим фактором изменения соотношения между выбранной архитектурой и функциями: можете ли вы предположить, что разработчики выберут проекты с исходным кодом, основываясь на соответствии архитектуры проекта и его функций их условиям эксплуатации? Если это так, то их вклад в разработку будет направлен в общем случае на улучшение работы в условиях эксплуатации, которым соответствует проект. Таким образом, проекты могут быть ограничены определенным набором функций, так как участники процесса разработки сами проявляют инициативу и могут избегать архитектур, которые не предоставляют нужных им возможностей. Это утверждение было, конечно же, справедливо в нашем случае, когда мы решили реализовать новую систему Pony-Build вместо внесения изменений в систему Buildbot: архитектура системы Buildbot просто не подходила для сборки сотен тысяч пакетов.
Существующие системы непрерывной интеграции в основном создаются с использованием двух различных архитектур и обычно реализуют только часть из полезных функций. С развитием систем непрерывной интеграции и ростом числа их пользователей, мы ожидаем реализации дополнительных функций: однако, реализация этих функций может быть обусловлена начальным выбором архитектуры. Будет интересно проследить процесс развития систем этого типа.
9.3.2. Благодарности
Мы благодарим Greg Wilson, Brett Cannon, Eric Holscher, Jesse Noller и Victoria Laidler за интересные обсуждения систем непрерывной интеграции в общем и системы Pony-Build в частности. Некоторые студенты участвовали в развитии системы Pony-Build, а именно Jack Carlson, Fatima Cherkaoui, Max Laite и Khushboo Shakya.
Продолжение статьи: К началу статьи.