Как и почему я устанавливаю машину сборки С#?

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

Какие инструменты/лицензии мне понадобятся? Прямо сейчас мы используем Visual Studio и Smart Assembly для сборки и Perforce для управления версиями. Будет ли мне что-то еще, или есть эквивалент задания cron для запуска автоматических скриптов? Что, собственно, это получит меня, кроме указания на сломанную сборку? Должен ли я настраивать тестовые проекты в этом решении (sln файл), который будет выполняться этими сценариями, поэтому я могу проверить определенные функции? На данный момент у нас есть два таких теста, потому что у нас не было времени (или, откровенно говоря, опыта), чтобы сделать хорошие модульные тесты. Какое оборудование мне нужно для этого? Как только сборка была завершена и протестирована, общепринятой практикой является создание этой сборки на ftp-сайте или другой способ для внутреннего доступа? Идея состоит в том, что эта машина создает сборку, и все мы идем к ней, но можем делать отладочные сборки, если нам нужно.
Как часто мы должны делать такую ​​сборку? Как управлять пространством? Если мы создадим ночные сборки, должны ли мы обойти все старые сборки или начать отрывать их примерно через неделю или около того? Есть ли что-нибудь еще, что я не вижу здесь?

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

EDIT: Я, наконец, получил его на работу! Хадсон совершенно фантастичен, и FxCop показывает, что некоторые функции, которые, как мы думали, были реализованы, на самом деле были неполными. Нам также пришлось сменить тип установки с Old-And-Busted vdproj на New Hotness WiX.

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

ОТВЕТЫ

Ответ 1

Обновление: Jenkins - самая современная версия Hudson. Теперь все должны использовать Дженкинса. Я буду обновлять ссылки соответственно.

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

Отчасти из старой почты:

Мы используем его для

  • Развертывание служб Windows
  • Развертывание веб-служб
  • Запустите MSTests и отобразите как можно больше информации, чем любые тесты junit.
  • Следите за низкими, средними и высокими задачами.
  • предупреждения и ошибки в трендах.

Вот некоторые из встроенных .net файлов, которые Hudson поддерживает

Кроме того, не дай бог, вы используете безопасный визуальный источник, он также поддерживает это. Я бы порекомендовал вам взглянуть на статью Redsolo о создании проектов .net с использованием Hudson

Ваши вопросы

  • Q: Какие инструменты/лицензии мне понадобятся? Прямо сейчас мы используем Visual Studio и Smart Assembly для сборки и Perforce для управления версиями. Нужно ли мне что-то еще или есть эквивалент задания cron для запуска автоматических скриптов?

  • A: Я только что установил визуальную студию на новую копию виртуальной машины, в которой была запущена новая исправленная установка операционной системы Windows. Таким образом, вам нужны лицензии, чтобы справиться с этим. Hudson установит себя как сервис Windows и запустится на порт 8080, и вы будете определять, как часто вы хотите, чтобы он сканировал ваш репозиторий кода для обновленного кода, или вы можете сказать, что он собирается в определенное время. Все настраиваемые через браузер.

  • Q: Что именно это даст мне, кроме указания на сломанную сборку? Должен ли я настраивать тестовые проекты в этом решении (sln файл), который будет выполняться этими сценариями, поэтому я могу проверить определенные функции? На данный момент у нас есть два таких теста, потому что у нас не было времени (или, откровенно говоря, опыта), чтобы сделать хорошие модульные тесты.

    A: Вы получите электронное письмо в первый раз, когда сборка завершится неудачей или станет нестабильной. Строка нестабильна, если unit test терпит неудачу или ее можно обозначить как неустойчивое с помощью любого количества установленных вами критериев. Когда сбой unit test или build не удастся, вы будете отправлены по электронной почте, и он сообщит вам, где, почему и как это произошло. С моей конфигурацией мы получаем:

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

  • Q: Какое оборудование мне понадобится для этого?

    A: В VM будет достаточно

  • Q: Как только сборка была завершена и протестирована, общепринятой практикой является создание этой сборки на ftp-сайте или другой способ для внутреннего доступа? Идея состоит в том, что эта машина создает сборку, и мы все к ней работаем, но можем создавать отладочные сборки, если нам нужно.

    A:. Хадсон может делать с ним все, что вам нужно, включая идентификацию его с помощью хеша md5, его загрузку, копирование, архивирование и т.д. Это делает это автоматически и предоставляет вам с долгой историей артефактов сборки.

  • Q: Как часто мы должны делать такую ​​сборку?

    A: У нас есть наш опрос SVN каждый час, ища изменения кода, а затем выполняется сборка. Ночь в порядке, но несколько бесполезная ИМО, поскольку то, над чем вы работали вчера, не будет свежим в вашем сознании утром, когда вы войдете.

  • Q: Как управляется пространство? Если мы производим ночные сборки, мы должны держать все старые сборки или начинать срывать их примерно через неделю или около того?

    А:Для вас, после столь долгого времени я перемещаю наши артефакты сборки в долгосрочное хранилище или удаляю их, но все данные, которые хранятся в текстовых файлах/файлах xml, которые я храню, позволяют мне хранить изменения, графики тенденций и т.д. сервер с небольшим количеством пространства verrrry. Также вы можете установить Hudson только для того, чтобы сохранить артефакты из завершающих # строчек

  • Q: Есть ли что-нибудь еще, что я не вижу здесь?

    A: Нет, пойди Хадсон прямо сейчас, ты не будешь разочарован!

Ответ 2

Нам повезло со следующим комбо:

  • Visual Studio (в частности, с помощью инструмента командной строки MSBuild.exe и передачи его файлов решений) устраняет необходимость в сценариях msbuild)
  • NAnt (например, XML-синтаксис/библиотека задач лучше, чем MSBuild. Также есть опции для операций управления P4 src)
  • CruiseControl.net - встроенная веб-панель мониторинга для создания/сборки.

CCNet имеет встроенные уведомители для отправки электронной почты при сбое/неудаче сборки

Об оправдании: это снимает нагрузку с разработчиков, выполняющих ручные сборки, и делает много, чтобы вывести человеческую ошибку из уравнения. Очень сложно количественно оценить этот эффект, но как только вы это сделаете, вы никогда не вернетесь. Наличие повторяющегося процесса создания и выпуска программного обеспечения имеет первостепенное значение. Я уверен, что вы были местами, где они создают программное обеспечение вручную, и он выходит в диком виде, только чтобы ваш парень по строительству сказал: "Ой, я, должно быть, забыл включить эту новую DLL!"

На аппаратном обеспечении: настолько мощный, насколько вы можете получить. Больше мощности/памяти = более быстрое время сборки. Если вы можете себе это позволить, вы никогда не пожалеете о том, чтобы создать первоклассную машину сборки, независимо от того, насколько маленькая группа.

В пространстве: Помогает иметь много места на жестком диске. Вы можете создавать свои скрипты NAnt для удаления промежуточных файлов каждый раз, когда начинается сборка, поэтому настоящая проблема заключается в том, чтобы вести истории журналов и старые установщики приложений. У нас есть программное обеспечение, которое контролирует дисковое пространство и отправляет оповещения. Затем мы очищаем диск вручную. Обычно это нужно делать каждые 3-4 месяца.

В уведомлениях о сборке: это встроено в CCNet, но если вы собираетесь добавить автоматическое тестирование в качестве дополнительного шага, тогда создайте его в проекте с самого начала. Когда проект становится большим, очень сложно проводить тесты на соответствие требованиям. Существует тонны информации о тестовых средах (вероятно, тонна информации о SO также), поэтому я буду откладывать называние каких-либо конкретных инструментов.

Ответ 3

На моем предыдущем рабочем месте мы использовали TeamCity. Это очень просто и эффективно использовать. Его можно использовать бесплатно с некоторыми ограничениями. Существует также учебник по Dime Casts. Причина, по которой мы не использовали CruiseControl.NET, состоит в том, что у нас было много небольших проектов, и очень сложно установить каждый из них в CC.NET. Я бы очень рекомендовал TeamCity. Подводя итог, если вы работаете с открытым исходным кодом, CC.NET - это великий папа с чуть более высокой кривой обучения. Если ваш бюджет позволит вам определенно пойти с TeamCity или проверить бесплатную версию.

Ответ 4

Как? Посмотрите на Carel Lotz blog.

Почему? Есть несколько причин, по которым я могу думать:

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

Статья Мартина Фаулера о Непрерывная интеграция остается окончательным текстом. Посмотрите на это!

Ответ 5

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

Проблема интеграции работы нескольких разработчиков - главная опасность для роста команды. Чем больше команда получает, тем сложнее скоординировать свою работу и помешать им возиться друг с другом. Единственное хорошее решение - сказать им "интегрироваться рано и часто", проверяя небольшие единицы работы (иногда называемые "историями" ) по мере их завершения.

Вы должны сделать сборку, которая будет восстанавливать КАЖДОЕ время проверки, в течение дня. С помощью системы круиз-контроля вы можете получить значок на панели задач, который становится красным (и даже говорит с вами!), Когда сборка нарушена.

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

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

Ответ 6

Просто пытаюсь немного подстроить то, что сказал mjmarsh, поскольку он положил большой фундамент...

  • Visual Studio. MSBuild отлично работает.
  • NAnt.
  • NantContrib. Это обеспечит дополнительные задачи, такие как операции Perforce.
  • CruiseControl.net. Это опять-таки ваша "панель управления".

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

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

NAnt включает задачи для nunit/ nunit2, поэтому вы можете фактически автоматизировать тестирование вашего устройства. Затем вы можете применять таблицы стилей к результатам и с помощью фреймворка, предоставленного CruiseControl.net, иметь хорошие читаемые, печатные unit test результаты для каждой сборки.

То же самое относится к задаче ndoc. Сделайте свою документацию выпущенной и доступной для каждой сборки.

Вы даже можете использовать задачу exec для выполнения других команд, например, создания установщика Windows с помощью InstallShield.

Идея состоит в том, чтобы автоматизировать сборку как можно больше, потому что люди совершают ошибки. Время, потраченное на фронт, экономит время по дороге. Людям не нужно нянчить сборку, пройдя процесс сборки. Определите все этапы сборки, создайте сценарии NAnt для каждой задачи и создайте свои сценарии NAnt один за другим, пока не полностью автоматизируйте весь процесс сборки. Затем он также помещает все ваши сборки в одном месте, что хорошо для сравнения. Что-то сломалось в Build 426, которое отлично работало в Build 380? Ну, есть готовые к тестированию результаты - возьмите их и проверьте.

Ответ 7

  • Никаких лицензий не требуется. CruiseControl.net свободно доступен и нужен только .NET sdk для сборки.
  • Сервер сборки, даже без автоматических модульных тестов, по-прежнему обеспечивает контролируемую среду для создания релизов. Больше не "Джон обычно строит свою машину, но он болен. По какой-то причине я не могу построить свою машину".
  • Сейчас у меня есть одна настройка в сеансе виртуального ПК.
  • Да. Сборка должна быть сброшена где-то доступной. В сборках разработки должна быть включена отладка. Выпуск сборки должен быть отключен.
  • Как часто это зависит от вас. Если вы правильно настроили, вы можете построить после каждой проверки, что будет очень мало накладных расходов. Это отличная идея, если вы имеете (или планируете иметь) модульные тесты на месте.
  • Сохраняйте вехи и релизы до тех пор, пока это необходимо. Все остальное зависит от того, как часто вы строите: постоянно? выбросить. Ежедневно? Держите неделю. Еженедельно? Сохраняйте стоимость в два месяца.

Чем больше ваш проект, тем больше вы увидите преимущества автоматической машины сборки.

Ответ 8

Это все о здоровье сборки. Что вы получаете, так это то, что вы можете настроить любые типы вещей, которые вы хотите выполнить с сборками. Среди них вы можете запускать тесты, статический анализ и профилировщик. Проблемы решаются намного быстрее, когда вы недавно работали над этой частью приложения. Если вы совершаете небольшие изменения, то он почти сообщает вам, где вы его сломали:)

Это, конечно, предполагает, что вы настроили его для сборки с каждой проверкой (непрерывная интеграция).

Он также может помочь ближе к QA и Dev. Поскольку вы можете настроить функциональные тесты для работы с ним, наряду с профайлером и чем-то еще, что улучшает обратную связь с командой разработчиков. Это не означает, что функциональные тесты выполняются с каждой проверкой (может занять некоторое время), но вы устанавливаете сборки/тесты с помощью инструментов, которые являются общими для всей команды. Я занимался автоматизацией тестов на дым, поэтому в моем случае мы более тесно сотрудничаем.

Ответ 9

Почему: 10 лет назад мы, как разработчики программного обеспечения, которые анализировали что-то в n-й степени, получили документы (написанные на человеческом языке) "подписаны", а затем начали писать код. Мы проверили бы unit test, строковый тест, а затем ударили бы системный тест: первый раз система в целом будет работать вместе, иногда неделя или месяцы после того, как мы получим документы, подписанные. Только тогда мы раскроем все предположения и недоразумения, которые у нас были, когда мы все проанализировали.

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

Как: Что касается того, как, я писал об этом немного назад: [Нажмите здесь]

Более 8 сообщений идут шаг за шагом о том, как настроить сервер Jenkins в среде Windows для .NET-решений.