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

Question

Вопрос новичка, терпите меня: мне просто интересно, при каких обстоятельствах следует использовать инструмент сборки, такой как nant или msbuild? Я работаю над приложением среднего размера (.net 3.0), каждый разработчик делает свою работу и строит на своем компьютере, проверяя изменения своего кода в хранилище по мере его поступления. Как только мы все закончим, я получу весь код из репозитория, сделаю чистую сборку на моем компьютере и разверну бинарные файлы. Просто из любопытства, откуда взялся инструмент для сборки?

Answer 1

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

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

Answer 6

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

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

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

Answer 7

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

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

Answer 8

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