Как стать автором
Обновить

Комментарии 7

не совсем понятно зачем изначально завязываться на коммит. раз есть ПР на вливание в основную ветку, то в любом случае надо проверить не сломают ли изменения сборку. а значит в битбакете достаточно настроить триггер на создание/правку ПР с вебхуком билда в тимсити
Мы в конце концов пришли к этому. Пока публиковалась статья, мы завезли решение на вебхуках) Для этого подняли небольшой сервис, который принимал запросы от вебхука битбакета (настроенного на обновления пул реквестов) и отправлял запросы на добавление билда в Teamcity.
А могли бы взять gitlab c gitlab-ci или jenkins'ом, и описывать свои пайплайны спокойно кодом. Но да, лучше бабки пилить, взять гит-сервер за дорого, есть кактус, писать на хабр какие костыли приходится изобретать.
У нашей компании закуплен Bitbucket server, поэтому используем его. Требования к инфраструктуре было чтобы все ресурсы, которые имеют доступ к коду находились на корпоративных серверах, поэтому мы не могли использовать облачные сервисы.
Насчет дженкинса — имхо, тимсити для нашей команды удобнее.
Проблемы стали всплывать не сразу, после некоторых обновлений Teamcity и Bitbucket.

Как это противоречит использованию гитлаб на своих мощностях? Что мешает динамически внутри вашей инфраструктуры масштабировать ранеры/агенты гитлаб/Дженкинс? Это всё риторические вопросы.
Если Дженкинс не зашёл, то гитлаб ci чем не угодил? Объективно причин выбора битбакета против гитлаб, только более глубокая crowd поддержка, которая полностью реализуется и на гитлабе дополнительными затратами, аналогичными вашим в описанном кейсе. В итоге выходит паритет, но при первоначальном выборе гитлаб выигрывает. Сейчас правда нет смысла вам менять инструмент.

Подскажите, пожалуйста, какая у вас версия TeamCity используется?
TeamCity Enterprise 2020.2.3 (build 86002)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий