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

Короткий ответ - всегда.

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

Это позволяет всем разработчикам, тестировщикам и роботам-сборщикам иметь последовательную, повторяемую сборку. Ведь Клавиша F5 - это не процесс сборки.

Если вы хотите что-то автоматизировать, лучше использовать nant / msbuild. Например: 1. зарегистрируйтесь 2. построить 3. тестирование и покрытие кода

Вы разрабатываете с помощью Visual Studio? В этом случае вы уже используете msbuild, поскольку это базовый механизм сборки Visual Studio. На самом деле файл проекта Visual Studio - это не что иное, как скрипт msbuild.

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

Я думаю, что любому нетривиальному приложению нужен «инструмент сборки». Мы используем термин «непрерывная интеграция» там, где я работаю. Бывают очень исключительные случаи (например: я создаю пример приложения, чтобы узнать, как работает функция X), но помимо них вы никогда не пожалеете о надежном процессе сборки.

Я предполагаю, что если бы команда разработчиков состояла из одного человека ... Я бы по-прежнему создал систему сборки, включая репозиторий, инструмент сборки и несколько наборов тестов. Да, поддержание системы сборки требует времени и денег, но это окупится (я работаю уже 40 месяцев над проектом, который начался с 6 разработчиков и сейчас включает около 30 разработчиков; это действительно окупилось для нас. раз) с точки зрения контроля качества, и чем раньше будут обнаружены проблемы с качеством, тем дешевле их будет исправить.

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

Соглашаясь с ответом zacherates и расширяя его ... Да, у вас всегда должен быть повторяющийся процесс сборки. Хотя технически проекты Visual Studio представляют собой файлы MSBuild, лучше, чтобы «официальный» процесс сборки был отделен от среды разработки.

На мой взгляд, это верно независимо от того, насколько велика (или мала) команда. Я использую NAnt и CruiseControl.NET дома, где все, над чем я обычно работаю, - это проекты и эксперименты. На работе мы используем аналогичную настройку, но немного более структурированную в том, как собираются сценарии NAnt.

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

Похоже, вы используете IDE для сборки. По сути, это инструмент для сборки; вы уже используете его. Вам следует сменить инструмент, когда тот, который вы используете, становится больше проблемой, чем решением.

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