Зачем использовать выделенный компьютер для сборки с использованием TFS? - PullRequest
5 голосов
/ 21 июля 2009

На сайте MSDN указано:

"... установить Team Foundation Build на компьютер, который предназначен для запуска сборок."

ОК, я понял. Но мой менеджер этого не сделал, и я не смог его убедить.

Таким образом, я прошу SO-сообщество помочь мне убедить его в необходимости использовать выделенный компьютер для запуска сборок.

Ответы [ 8 ]

8 голосов
/ 21 июля 2009

Сборка - это процесс, интенсивно использующий процессор. Идея сервера сборки заключается в том, что он сидит и собирается после каждой регистрации, чтобы убедиться, что ничего не сломалось. Если вы поместите это на компьютер с другими ресурсами, это замедлит все остальное. Даже если вы виртуализировали его, это, вероятно, будет проблемой.

Другое дело, что вам нужна «чистая» установка ОС, чтобы другие программы не загрязняли компьютер, добавляя зависимости, которые могут отсутствовать у клиентских компьютеров.

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

4 голосов
/ 21 июля 2009

Установите свой сервер сборки на своем ПК, а затем используйте его для непрерывной интеграции, пока он не поймет, зачем ему нужен собственный сервер;)

Я отдам за час до того, как он позвонит вашему поставщику оборудования, чтобы он предоставил вам новый сервер.

2 голосов
/ 21 июля 2009

Для одной из воспроизводимых сред фраза «Но это работает на моей машине» больше не будет слышна. Он снимает нагрузку с машин разработчика и гарантирует, что все в курсе и все проверено.

Статья Джоэла Спольскиса может быть полезна для вас (немного позже середины, где он говорит о сервере ежедневной сборки).

На этот вопрос также есть еще несколько ответов.

1 голос
/ 21 июля 2009

Вы хотите, чтобы сборка выполнялась максимально быстро, особенно если вы выполняете непрерывную интеграцию или если у вас большой процесс сборки. Недавно мы начали бороться с нашим ИТ-отделом, потому что серверы, которые мы используем для сборки и тестирования, работают слишком медленно. Это происходит главным образом потому, что они все работают как виртуальные машины, и у них слишком много виртуальных машин на хост. Наш полный процесс сборки (не сборка CI) теперь занимает более получаса (в основном это развертывание, а не компиляция), и это убивает наших сотрудников QA, поскольку им приходится слишком долго ждать сборки.

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

1 голос
/ 21 июля 2009

Вы также можете включить тесты, которые запускаются автоматически после сборки, включая модульные тесты и тесты производительности. Система может быть настроена на экспорт полнофункционального установщика, который можно сделать доступным во внутренней сети для других отделов для загрузки и использования / тестирования. Это экономит много времени и денег, если вам приходится делать это каждую неделю или месяц.

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

0 голосов
/ 21 июля 2009

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

0 голосов
/ 21 июля 2009

В качестве упражнения спросите менеджера, какая машина подойдет для сборки сервера? Его машина? Машина другого разработчика? Стоимость запуска этого процесса на компьютере разработчика будет плохой.

Ради аргумента, давайте допустим, что разработчик запустит это на своем компьютере. Это все еще, вероятно, чистый позитив по сравнению с отсутствием машины для сборки.

В скором времени я подозреваю, что менеджер и команда поймут, что нужна новая машина.

Несмотря на статью Spolsky, на которую ссылается кто-то другой, сборочная машина не обязательно должна быть самой быстрой коробкой ... Это может быть отработанная машина из вторых рук.

Как только команда увидит и ощутит преимущества сервера сборки, она совершит естественный переход к выделенной машине. (если нет, то пора бежать)

Некоторые конкретные причины для этого (как уже говорили)

  1. Воспроизводимость и стабильность сборок. Крайне важно, чтобы сборки были последовательными и повторяемыми. Существует значительно больший контроль над сервером сборки, чем на всех различных машинах разработчика. Это позволяет разработчикам пробовать инструменты Beta dev и т. Д., Не затрагивая релиз / сборку.

  2. Эффективность - использование выделенного сервера сборки освобождает ЦП машин разработчика для разработчиков.

0 голосов
/ 21 июля 2009

Я исхожу из того, что серверы должны быть предназначены для выполнения конкретной задачи. Например, контроллер Active Directory не должен дублироваться как сервер SQL.

С учетом имеющихся ресурсов становится трудно сбалансировать нагрузку между несколькими серверными приложениями. Например, сервер сборки, выполняющий сборку, может повлиять на производительность любых других служб на коробке. Вполне вероятно, что ваш сервер сборки будет использоваться для создания множества различных проектов. Компиляция и множество задач, связанных с типичной сборкой (например, анализ кода, модульное тестирование и т. Д.), Являются дорогостоящими и ресурсоемкими операциями.

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

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

...