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

https://stackoverflow.com/questions/616149

03-07-2019
|

Вопрос

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

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

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

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

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

Как часто мы должны выполнять такого рода сборки?

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

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

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

Редактировать:Наконец-то у меня получилось!Хадсон совершенно фантастический, и FxCop показывает, что некоторые функции, которые, как мы думали, были реализованы, на самом деле были неполными.Нам также пришлось изменить тип установщика со Старого и неисправного vdproj на Новый Hotness WiX.

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

Решение

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

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

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

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

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

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

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

Ваши вопросы

Q:Какие инструменты / лицензии мне понадобятся?Прямо сейчас мы используем Visual Studio и Smart Assembly для сборки и Perforce для управления версиями.Понадобится ли мне что-то еще, или есть эквивалент задания cron для запуска автоматических скриптов?
A: Я только что установил visual Studio на новую копию виртуальной машины, на которой выполняется свежая, исправленная установка ОС Windows server.Так что вам понадобятся лицензии, чтобы справиться с этим.Hudson установится как служба Windows и запустится на порту 8080, и вы настроите, как часто вы хотите, чтобы он проверял ваше хранилище кода на наличие обновленного кода, или вы можете указать ему выполнять сборку в определенное время.Все настраивается через браузер.
Q: Что именно это даст мне, кроме указания на неисправную сборку?Должен ли я настроить тестовые проекты в этом решении (файл sln), которые будут запускаться этими скриптами, чтобы я мог протестировать определенные функции?На данный момент у нас есть два таких теста, потому что у нас не было времени (или, честно говоря, опыта) для создания хороших модульных тестов.

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

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

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

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

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

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

Другие советы

Нам очень повезло со следующей комбинацией:

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

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

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

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

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

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

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

Каким образом?Взгляните на Карела Лотца Блог.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow