Как и зачем мне настроить машину для сборки C #?

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

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

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

Мы используем это, чтобы

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

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

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

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

Ваши вопросы

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

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

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

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

  • list of all commits since the last working build
  • зафиксировать записи этих коммитов
  • список файлов, измененных в коммитах
  • вывод консоли из самой сборки, показывающий ошибку или сбой теста

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

  A: Достаточно виртуальной машины

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

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

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

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

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

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

• В: Я что-то еще здесь не вижу?

  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.
• NantContrib. Это обеспечит дополнительные задачи, такие как операции Perforce.
• CruiseControl.net. Это опять же в основном ваша «панель управления сборкой».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В более чем 8 публикациях пошагово рассказывается, как настроить сервер Jenkins в среде Windows для решений .NET.