обо всем по порядку. Мой CI-сервер - это виртуальная машина под управлением CruiseControl.NET. Я не использую Jenkins, поэтому я не могу это прокомментировать. Судя по всему, Jenkins более развит, чем CC.NET.
В соответствии с виртуальным и физическим вопросом: в конечном счете, это не имеет значения, насколько это касается CI. Пока он виден в сети и имеет достаточно ресурсов для выполнения своих функций, остальное - только администрирование. Лично я считаю, что преимущества виртуализации стоят дополнительных усилий. Вы можете легко добавлять ресурсы, перемещать их физическое местоположение, вставлять дополнительные виртуальные машины для запуска кластера. преимущества виртуализации хорошо известны, и все делают это в наши дни.
Мой CI-сервер находится на сервере VMWare ESX, который имеет тонну ЦП и ОЗУ для разгрузки. На нем работает много других виртуальных машин. У меня около 35 сайтов, работающих через CI, и, вероятно, 20 размещены на самой машине, и еще 70 сайтов, которые собираются создавать, вручную вызывая их через панель мониторинга CI. У меня никогда не было с этим проблем с производительностью.
Ваш сервер сборки в идеале должен иметь ту же настройку, что и машины, на которых вы планируете развертывать свой код. Для веб-сайтов это будет та же ОС, что и на ваших производственных серверах (вероятно, Windows 2003 или 2008). Для настольных приложений я бы, наверное, просто выбрал последнюю и лучшую ОС, на которую вы ориентируетесь и которую можете себе позволить.
Использование нескольких компьютеров с несколькими ОС будет уместно только при создании настольных приложений, которые вы пытаетесь поддерживать на нескольких ОС. В этом случае было бы идеально иметь несколько серверов, но я вижу, что для настройки нужно много работы. Лично я бы начал просто, запустил все и начал добавлять кусочки, когда они стали действительно необходимыми.
Как я уже говорил, я использую CruiseControl.NET. Пока это было здорово, и я доволен этим. Поскольку он написан на .NET, а вы используете .NET, для запуска вашего сервера требуется меньше движущихся частей (я вижу, что Jenkins построен на Java). Написание плагинов / расширений было бы теоретически проще, так как у вас уже есть .NET люди в доме. Я никогда не писал расширение для CC.NET, поэтому не могу сказать это с уверенностью, хотя знаю, что это возможно. Недостатком является то, что сообщество маленькое, а активное развитие идет медленно.
Наконец, я добавлю, что это будет МНОГО работы, чтобы начать. Мне потребовалось более 6 месяцев, чтобы подготовить мой CI-сервер к работе, еще несколько - перенести все наши проекты для его выполнения и еще много - на то, чтобы обучить остальных разработчиков тому, как его использовать или работать с ним.
Итак, в итоге,
- Виртуализация это хорошо! (но это не имеет значения).
- Вы должны сопоставить свою среду CI с тем окружением, в котором вы развертываете, если это возможно.
- Тебе лучше быть готовым совершить долгую поездку.
- Непрерывная интеграция великолепна, и вы не пожалеете о настройке CI-сервера. Что бы вы ни выбрали, это будет лучше, чем "ковбойское кодирование", которое продолжалось :)
РЕДАКТИРОВАТЬ Другие ответы публикуют свой процесс, поэтому я думаю, что я должен был сделать это тоже! :)
Мой магазин создает сайты LAMP и .NET, поэтому нам нужно что-то, что могло бы эффективно работать с обоими. У нас в качестве базовой платформы работает CC.NET, но почти все функции выполняются с помощью пользовательских Nant сценариев. Мы используем Nant, потому что он 1) основан на .NET и имеет встроенные команды .NET и 2) легко выполняет операции командной строки, которые составляют ядро всех наших этапов сборки.
CC.NET прослушивает сервер SVN и получает обновления по мере их поступления. CC.NET проверяет их и запускает задачу NANT, которая выполняет всю реальную работу. Для .NET это означает mstest для модульного тестирования и msbuild для сборки и публикации. PHP обычно просто перемещает файлы прямо в среду назначения. Затем, если все шаги были выполнены успешно, Robocopy скопирует файлы на конечный сервер, который был сопоставлен как сетевой диск во время сценария запуска групповой политики (серверы Windows сопоставлены с net use и серверы LAMP сопоставляются с Webdrive ).
У нас есть серверы разработки, промежуточные / QA-серверы и производственные серверы. Поскольку мы работаем в .NET и LAMP, у нас есть один сервер на среду для каждого из этих этапов - всего 6, и все они виртуальные. Наши серверы разработки - единственные, которые настроены на непрерывную интеграционную сборку. Подготовка и производство выполняются принудительно только вместе с некоторыми другими SVN-мастерами, чтобы предотвратить случайное развертывание. Мы также собираем и тестируем AcrionScript, используя MXMLC , но это редко для нас.