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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

system.agent.name does not equal teamcity1 

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

Answer 3

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

Answer 4

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

Теперь мы должны сделать сборку и сборку тестов на разных ОИМ, что делает практически то же самое.