Как и почему я настраиваю машину сборки C #? [закрыто]

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

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

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

Частично из моего старого поста:

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

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

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

• MSBuild
• NAnt
• MSTest
• Nunit
• Team Foundation Server
• FxCop
• StyleCop
• предупреждения компилятора
• код задачи

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

Ваши вопросы

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

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

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

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

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

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

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

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

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

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

  A: Мы проводим наш опрос SVN каждый час, ищем изменения кода, затем запускаем сборку. Nightly - это нормально, но несколько бесполезно IMO, потому что то, над чем вы работали вчера, не будет свежим в вашем утре, когда вы входите.

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

  Ответ: Это зависит от вас, после столь долгого времени я перемещаю наши артефакты сборки в долговременное хранилище или удаляю их, но все данные, которые хранятся в текстовых файлах / XML-файлах, которые я храню, это позволяет мне сохранять журнал изменений, графики тенденций, и т. д. на сервере с очень небольшим занимаемым пространством. Также вы можете настроить Hudson так, чтобы артефакты не попадали только из-за количества сборок.

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

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

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

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

CCNet имеет встроенные уведомители для отправки электронных писем, когда сборки удаются / не удаются

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

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

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

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

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

Как? Загляните в блог Карела Лотца .

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

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

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

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

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

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

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

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

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

• Visual Studio. MSBuild работает отлично.
• NAnt .
• НантКонтриб . Это обеспечит дополнительные задачи, такие как выполнение операций.
• CruiseControl.net . Это опять-таки в основном ваша «панель инструментов сборки».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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