Непрерывная интеграция Jazz SCM — поток сборки vs.Рабочее пространство?

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

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