Непрерывная интеграция Jazz SCM - создать поток по сравнению с рабочим пространством?

Question

Я нахожусь в процессе настройки сборки непрерывной интеграции для приложения Spring Roo, используя IDE Rational Team Concert (RTC) и механизм сборки Jazz.При настройке определения сборки в поле «Рабочая область сборки» на вкладке «Управление исходным кодом Jazz» можно выбрать либо рабочую область хранилища пользователя, либо поток.

Рекомендации по непрерывной интеграции RTC и другие ресурсы сборки Jazz постоянно ссылаются на использование выделенного рабочего пространства хранилища, связанного с пользователем сборки, что позволяет мне полагать, что это предпочтительный подход.Я не смог найти никакой информации о строительстве непосредственно из потока.Поток нашего проекта содержит все артефакты, необходимые для сборки, и я проверил и подтвердил, что непрерывная интеграция работает из потока.Я не могу придумать причину, по которой мне нужно было бы создавать и управлять конкретным рабочим пространством для этой цели.

Мой вопрос: играю ли я с огнем, строя прямо у ручья?Есть ли потенциальные последующие осложнения с этим подходом, о которых я не знаю?

Answer 1

Отвечая на мой собственный вопрос в случае, если у другого пользователя SO будет такой же вопрос в будущем.

После некоторых экспериментов я обнаружил, что недостатком сборки непосредственно из потока является то, что он игнорирует свойство "Сборка только при наличии изменений, принятых" на вкладке Jazz Source Control. В результате сборки из потока могут выполняться только через заранее определенные интервалы - невозможно настроить сборку так, чтобы она происходила только тогда, когда в поток были внесены новые изменения.

Для сборки требуется выделенное рабочее пространство, чтобы принимать новые изменения из потока и использовать их для запуска запроса на сборку.

Answer 2

Здесь есть еще одна БОЛЬШАЯ разница.Это связано с тем, КАК сборка завершена.Позвольте мне подчеркнуть разницу здесь.

Если вы выполняете сборку из выделенной рабочей области хранилища сборок, то в вашей рабочей области сборки уже есть копия всего кода.Когда ваши изменения доставлены и сборка начата, то только измененные файлы (ваш набор изменений) необходимо обновить и физически скопировать из репозитория в рабочую область репозитория сборки.Поскольку большинство изменений невелики, это включает в себя копирование от 0,1% до 2% вашей кодовой базы из хранилища.

Если вы строите из «потока», то ваше рабочее пространство для сборки должно быть создано (вынадо где-то скомпилировать!).Поэтому, когда это будет создано, ваша ВСЯ кодовая база должна быть обновлена ​​и физически скопирована из репозитория в рабочую область репозитория сборки.Это означает получение 100% вашей кодовой базы из хранилища.

Каждая файловая операция включает в себя вызов для обнаружения необходимого ресурса, выборки этого ресурса из базы данных, в которой находится хранилище, и затем приложение Jazz предоставляет этот исходный файл.по сети.Это приводит к нагрузке на сервер базы данных, веб-сервер и сервер приложений.Чем больше вы загружаете таким образом, тем больше нагрузка на эти компоненты.

Есть некоторые вещи, которые вы можете использовать, чтобы минимизировать эту нагрузку на инфраструктуру Jazz.Использование прокси-серверов для кэширования содержимого (с использованием простого прокси-сервера Squid) может помочь.

Для получения более подробной информации о ваших опциях здесь и относительных достоинствах этих опций, прочитайте мой пост в блоге и технический документ по проблемам производительности Jazz (http://dtoczala.wordpress.com/2013/02/11/jazz-performance-a-guide-to-better-performance/). Этой статье уже почти год, но она по-прежнему остается в силе. Вы также можете ознакомиться с Jiki Deployment Wiki (https://jazz.net/wiki/bin/view/Deployment/WebHome), и ознакомиться с разделами, посвященными устранению неполадок и проблемам производительности.