Как вы работаете с сервером сборки? - PullRequest
14 голосов
/ 20 января 2009

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

Нет сомнений, что одна из этих вещей - это сервер сборки, вопрос в том, как далеко вы должны зайти.

  • Каковы минимальные требования к серверу сборки? (Где-нибудь просто скомпилировать?)
  • Какова конечная цель вашего сервера сборки? (Запланировано, интеграция с управлением исходным кодом, автоматическое развертывание на тестовых / живых серверах)
  • Где хорошее место, чтобы начать предполагать, что у вас сейчас ничего нет?

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

Было бы также хорошо услышать о людях, которые считают, что у них есть «полная» настройка системы, которая выполняет все функции, которые им требуются, и как они собирались все настроить с нуля.

Ответы [ 12 ]

12 голосов
/ 20 января 2009

Вы можете начать с просмотра Круиз-контроль .

Также есть CruiseControl.net , если это ваш яд.

По сути, вам нужны следующие ингредиенты:

  • Выделенная среда (Виртуальная машина / сервер. Не используйте машину разработчика, если только это не вы. Даже тогда, если можете, запустите ВМ. Гораздо проще перенести ее на сервер, когда / если она станет доступной в ваша организация)
  • Система контроля версий, которая поддерживает помеченные / помеченные ревизии (например, Subversion + TortoiseSVN )
  • Сборка скриптов. Это могут быть пакетные файлы, которые запускают приложения devenv.exe или msbuild.exe из командной строки, или вы можете использовать что-то вроде Ant или NAnt .

В этом сценарии CruiseControl действует как сервер Continous Integration и может удостовериться, что вы выполнили сборки при проверке кода. Это означает, что вы знаете, является ли сборка поврежденной быстрее, чем если бы у вас только что были ночные сборки. Возможно, вы также должны иметь ночные сборки.

4 голосов
/ 20 января 2009

Гудзон - отличный CI.

Мы запускаем ферму локально, но мы начали с загрузки hudson.war и выполнения

java -jar hudson.war

Он интегрируется с SCM, системы отслеживания ошибок - это действительно круто.

Вам понадобится место на диске, если вы хотите сохранить старую сборку.

Наслаждайтесь, это пока самое простое решение CI.

НТН, Hubert.

2 голосов
/ 22 января 2009

Круиз, Мейвен, Хадсон и т. Д. Все великолепны, но всегда стоит иметь решение с временным интервалом.

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

Спецификация машины сборки не обязательно важна, если у вас нет проекта монстра. Мы стараемся сократить время сборки до 10 минут (включая модульные тесты), и у нас довольно большой проект.

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

2 голосов
/ 20 января 2009

Начните с прочтения превосходной статьи Мартина Фаулера о Непрерывная интеграция .

Мы создали такую ​​систему для крупного проекта> 2000 kSLOC, и она зарекомендовала себя как бесценная.

НТН

ура

Rob

2 голосов
/ 20 января 2009

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

Для базового сервера сборки - используйте одно из предложений CI, которое отслеживает управление исходным кодом и запускает сборку при обнаружении изменений. например: cruiseControl.

Как только вы соберете базовую сборку - добавьте выполнение ваших модульных тестов после успешной сборки.

Самая успешная система, которую я имел, имела 3 разных сборки: - - тот, который запустил при регистрации - все, что он сделал, было построить код. - по требованию, который будет создавать приложение, генерировать установщик и затем помещать установщик в общий диск для тестеров, чтобы забрать - ежедневная сборка, запускаемая в 10 вечера. Это: - выполнил генерацию кода для построения кода БД и C # из модели UML - построить код - создал нового тестового пользователя для проверки сборки на тестовом экземпляре Oracle - запустил схему приложения в БД - запустил кучу юнит-тестов - очистил пользователя БД (если тесты прошли успешно) - запустил анализ покрытия для составления отчета о покрытии кода единицы

Программное обеспечение, которое мы использовали для этого, было NANT, CruiseControl.NET, пользовательская система генерации кода, пользовательское приложение для построения схемы Oracle и NCover для анализа кода.

2 голосов
/ 20 января 2009

Если вы используете круиз-контроль, вам нужно запустить Ant build.xml, который выполняет работу вручную.

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

Вам нужны тесты JUnit для запуска с помощью задачи Ant и создания отчетов HTML.

1 голос
/ 19 октября 2009

Примерно по порядку - минимальный / наименее сложный, через более сложный

  • возможность получить определенный набор источников на любой машине
  • возможность построить этот источник (без проблем)
  • возможность (график) строить каждую ночь / или какой-то другой определенный период без вмешательства пользователя
  • Один (или более) выделенный сервер сборки (не является общим для qa или dev-машины)
  • может сделать сборку после каждой регистрации / коммита
  • Уведомить заинтересованные стороны о статусе сборки после сборки
  • Предоставление статуса сборки в любое время
  • Создание инсталляторов как часть сборки
  • возможность развертывания / прямой трансляции, если сборка хорошая
  • Запуск юнит-тестов
  • Выполнить тестирование продукта
  • Сообщить о результатах этих испытаний
  • Статический анализ кода и отчетность ... И этот список можно продолжать и продолжать

Не бойтесь начинать с пакетных файлов, сценариев оболочки или других специальных средств. Люди делали совершенно хорошее программное обеспечение до того, как увлеклись CI. было много хороших процессов до того, как Хадсон и Круиз-контроль - (я не выбиваю тех или других - я использую Хадсон среди других) - но не упустите момент - эти вещи здесь, чтобы помочь вам - не становиться властным процессом)

1 голос
/ 20 января 2009

Я использую Cruisecontrol.NET и сборочный скрипт msbuild.

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

Кроме того, мой сервер сборки CruiseControl.NET также использует этот скрипт. Он регулярно проверяет наличие изменений, внесенных в систему контроля версий.
Если это произойдет, CC.NET выполняет задачу get-latest, которую я определил в buildscript, собирает все, выполняет модульные тесты и выполняет статический анализ кода (fxcop).

Мой 'buildserver' - это просто старая рабочая станция. Это PIV, 3Ghz с 1 Гб оперативной памяти, и он отлично справляется со своей работой.

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

Я думаю, что это хорошее место для начала: [http://confluence.public.thoughtworks.org/display/CC/Home;jsessionid=5201DA7E8D361EB164C40E519DA0F0DE][1]

По крайней мере, именно здесь я начал искать, когда настраивал свой сервер сборки. :)

[1]: Дом CruiseControl

0 голосов
/ 02 ноября 2009

Мы начнем с написания пакетных сценариев, которые будут запускаться на компьютере разработчика. Когда все процессы автоматизированы, мы перемещаем их на сервер сборки.

В области инструментов мы в настоящее время переходим от круиз-контроля к TFS.

0 голосов
/ 20 января 2009

Попробуйте и найдите что-то, что соответствует вашим существующим практикам с точки зрения построения - например, это не будет подходящим вариантом, чтобы попробовать & использовать сервер сборки на основе Ant, если вы используете Maven, например!

В идеале, он должен просто иметь возможность контролировать вашу систему контроля версий, извлекать код, создавать, запускать некоторые тесты и публиковать результаты, не зная об этом, или, по крайней мере, до тех пор, пока он не сообщит об ошибке. Лично я бы рекомендовал Хадсон (https://hudson.dev.java.net/)) в качестве хорошей отправной точки, поскольку его легко установить и запустить, и у него приличный интерфейс.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...