Совместное использование TeamCity между двумя разными командами

Question

Наша команда имеет полную лицензию на сервер TeamCity, а также 7 дополнительных агентов. Другая не связанная команда достигла пределов своей бесплатной лицензии TeamCity и следит за нашими лицензиями.

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

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

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

Как внутреннее чувство, это не выглядит хорошей идеей ...

edit: Помимо этого, Хадсон делает это лучше? Архитекторы из башни из слоновой кости хотят, чтобы мы перешли с TeamCity на Hudson, потому что другие люди используют Hudson. Если я скажу им, что совместное использование TeamCity не будет работать, лагерь Хадсона, вероятно, будет использовать его как палку, чтобы побить нас. Джой.

Answer 1

Не уверен, какую версию TeamCity вы используете, но недавно выпущенный TeamCity v7.0 теперь имеет новую функцию пула агентов, которая обеспечивает гораздо более простой способ распределения агентов.Он может быть вам интересен, за дополнительной информацией обращайтесь к разделу Что нового или к документам Agent Pools .

У меня была похожая проблема с нашими двумя отделаминачать использовать тот же экземпляр TeamCity, чтобы сэкономить на расходах на дополнительные лицензии.Я должен признать, что у нас действительно не было никаких проблем, кроме того, что наши агенты были теперь вдвое заняты.

Я включил Разрешения для каждого проекта на странице Глобальные настройки и создал 2 группы пользователей,один для «нас», а другой для «них».Затем вы можете настроить роли каждой группы соответственно.Если группа не имеет роли Просмотр проекта для проекта, она не отображается для них - отличный способ показать только необходимые проекты для группы;но есть множество других вариантов ролей.

Я никогда не использовал Хадсон, поэтому, к сожалению, сравнивать не могу.Я должен действительно попробовать это, но так как я всегда так хорошо ладил с TC, у меня никогда не было причины тоже.

Answer 2

Мы больше не делаем этого, но мы использовали для разделения наших агентов на псевдопулы, чтобы мы могли зарезервировать некоторые для компиляций, а другие для автоматических тестов (потому что автоматизированные задания тестирования могут затопить сетку). Мы добавили свойство «can_run_tests» к тестовым агентам и заставили эти сборки требовать это свойство в качестве условия агента. Он отлично работал, и это то, что вы можете испечь в AMI для набора облачных агентов.

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

Answer 3

Другая команда может создать новый сервер Teamcity, и у него будет свой новый набор бесплатных конфигураций и агентов сборки.

Answer 4

Сборки можно выполнять при запуске на определенном агенте из конфигурации сборки каждой сборки в разделе требований к агенту, тем самым ограничивая любую конфигурацию сборки определенными агентами.Например, если ваш агент для одной команды - teamcity1, вы можете указать:

system.agent.name  does not equal teamcity1

Так что он никогда не будет работать на этом агенте.Таким образом, вы можете как минимум скопировать конфигурации сборки, и они будут работать на отдельных агентах без конфигурации агента-скрипта.