Каковы плюсы и минусы в создании автоматизированной системы сборки для каждого проекта в .Net? - PullRequest
1 голос
/ 17 октября 2010

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

psake - отличная среда для создания автоматизированной сборки.строить.Проблема, которую я всегда испытываю, заключается в изучении PowerShell для выполнения более сложных задач.Я уверен, что то же самое можно сказать о NAnt, msbuild и т. Д.

Моя идея решить эту проблему - создать систему сборки для данного решения в .Net.Базовая структура процесса будет выглядеть так:

build.bat

rem // Set the environment for msbuild.
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\vcvars32.bat"

rem // Build the solution's builder.
msbuild.exe buildsolution.csproj

rem // Run the solution's builder.
BuildSolution.exe <task>

BuildSolution проекта

Крошечныйконсольное приложение, которое:

  • Ссылается на структуру BuildSolution.
  • Включает метод для каждой задачи.Например:
    • Очистить
    • Сборка
    • Тест
    • Подтвердить
  • Регистрирует задачи и их зависимости,он может работать.Например:
    • Builder.RegisterTask (x => x.Clean)
    • Builder.RegisterTask (x => x.Build) .DependsOn (x => x.Clean)
    • Builder.RegisterTask (x => x.Test) .DependsOn (x => x.Build)
    • Builder.RegisterTask (x => x.Commit) .DependsOn (x => x.Test)
  • Запускает строитель.например, Builder.Execute ()

Тестовое задание

В конечном итоге тестовое задание вызовет nunit, mstest, xunit и т. д., но сначала строит требуемую командную строку.Это пример того, как использование .Net вместо PowerShell является для меня победителем.

При разработке своих приложений я придерживаюсь простого соглашения об именах ProjectName и ProjectName.Tests.Система сборки ищет файл * .Tests.dll и включает их в командную строку mstest.

Преимущества использования приложения .Net для построения этой задачи:

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

Сводка

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

Какие минусы вы видите для идеи BuildSolution?

1 Ответ

4 голосов
/ 17 октября 2010

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

Плюсы:

  • Это маленький
  • Это просто учиться
  • Это просто для отладки
  • Легко представить исправление ошибки
  • Вам не нужно запрашивать новые функции в

Минусы:

  • Вы заново изобрели колесо (это всегда добавляет стоимость. Стоит ли вам оценивать, сколько это стоит)
  • Вы не можете нанимать людей, которые уже знают вашу систему сборки
  • Вы должны внедрить свои собственные исправления ошибок (да, у вас будут ошибки), и не можете позволить кому-то за пределами компании позаботиться об этом, не заплатив им
  • Вы не можете гуглить свои ошибки в Интернете, потому что никто не знает, что они у вас есть
  • Если он используется несколькими группами, вам нужно превратить его в настоящий проект с вехами, отставанием, базой ошибок и т. Д.
  • Если вы решили не превращать его в центральный проект, вы дублируете код. Исправления ошибок не будут передаваться между различными копиями кода.
  • Вам не хватает тонны функций из существующих систем сборки (например, интеграция в вашу IDE или другое программное обеспечение, мониторинг, встроенные отчеты, встроенные уведомления о работоспособности, управление лабораторией и т. Д.)
  • Вы не сможете Google, если кто-то знает, как интегрировать продукт X в ваше решение, не выполняя при этом дополнительную работу (т. Е. Кодируя новую функцию)

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

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

...