Я не говорю что есть проблемы. Я говорю что это займет совсем не час.
Только для этих задач CI совсем не при чем.
А про студию я не про сборки говорил, а именно про "задружить с IDE".
А зачем? Есть выделенная машина, на которой все сборки происходят, причем это по идее нейтральная машина, на которой ничего кроме сборок и не происходит. Это позволяет минимизировать "works on my machine" эффект.
IDE для этого не нужен. К тому же, если уж так надо, то сама Visual Studio по идее имеет аналогичные системы. Достаточно покопаться в инструментарии.
Установка "голого" хадсона это да, быстро. Но там есть еще ряд задач, начиная от подготовки машинки под хадсон (да и просто билдагенты... не на рабочей же машине всем этим заниматься) и заканчивая прикручиванием всего что нам может понадобиться.
Дополнительные полчаса. А если что-то не включено сразу, то можно добавлять по мере необходимости.
Тоже не совсем верно.
1. Есть набор GUI-level задачек для которых CI совсем не нужен. Это могут быть громоздкие тесты, роботы генерящие тесты и так далее. Там шедулеров как правило достаточно, потому что по сути все что можно взять от той же CI для этой задачи это ее шедулер (который у того же хадсона вроде как не сильно от того же cron отличается, нет?).
Для роботов, генерящих тесты и шедулер не нужен, как правило. В-основном это потому что генерация тестов - задача разовая, то есть нету необходимости именно в систематическом повторении.
С громоздкими тестами всё ещё веселее. Как минимум CI решение и шедулер здесь одинаковы, хотя бы потому, что действительно CI может задействовать тот самый шедулер. Но есть одно серьезное отличие, которое проявляется как раз на больших объемах тестов, которые гоняются регулярно. Более-менее серьезные автоматизационные проекты к этому со временем приходят, когда суммарное время выполнения тестов превышает 24 часа. То есть на ежедневной основе такие тесты не позапускаешь. Вот тут CI система и поможет. Помимо запусков по расписанию можно выполнять запуски по определенному событию, например, после определенной сборки. В этом случае мы можем создать 2 задачи, каждая из которых стартует сразу после другой. Эдакий бесконечный цикл получается. При прикрученной нотификации (пара кликов) и централизованном хранилище отчетов (пара минут настройки параметров сборки) мы практически полностью автоматизируем выполнение тестов.
2. Под конвейером я имел ввиду конторы занимающиеся такими задачами.
На самом деле со временем с выбором инфраструктуры ограничены все, так как ставить с нуля - это одно, а мигрировать с одной системы на другую - это совсем другое.
А есть еще большие компании со своими стандартами, которые пользуются не совсем стандартными системами контроля версий, багтрекерами и так далее.
Большинство из них подбирают более-менее распространенные системы для построения инфраструктуры, так что тут проблем нет. Баг-трекер (в контексте исходной задачи он и близко не нужен. но все-таки), может и будет какой-то кастомизированный, но в остальном проблем быть не должно.
