Почему нужно использовать систему сборки по тому, что включено как часть IDE?
Я услышал, что больше чем один человек говорит, что, если Ваш процесс сборки нажимает кнопку сборки, чем Ваш процесс сборки, повреждается. Часто это сопровождается с советом использовать вещи как make, cmake, nmake, MSBuild, и т.д., Что точно эти инструменты предлагают, который выравнивает по ширине вручную поддержание отдельного конфигурационного файла?
Править: Я больше всего интересуюсь ответами, которые относились бы к единственному разработчику, работающему над ~20k строкой проект C++, но я интересуюсь общим случаем также.
EDIT2: не похоже, что существует один хороший ответ на этот вопрос, таким образом, я шел вперед и сделал это CW. В ответ на тех, которые говорят о Непрерывной Интеграции, да, я понимаю полностью, когда у Вас есть многие разработчики на проекте, имеющем CI, хорошо. Однако это - преимущество CI, не поддержания отдельных сценариев сборки. Они являются ортогональными: Например, Сборка Основы Команды является решением CI, которое использует файлы Visual Studio проекта, поскольку это - конфигурация.
5 ответов
Помимо потребностей непрерывной интеграции, которые все остальные уже рассмотрели, вы также можете захотеть автоматизировать некоторые другие аспекты процесса сборки. Возможно, это что-то простое, например, увеличение номера версии в производственной сборке, или запуск модульных тестов, или сброс и проверка тестовой среды, или запуск FxCop или пользовательского скрипта, автоматизирующего проверку кода на соответствие корпоративным стандартам. Сценарий сборки - это просто способ автоматизировать что-то в дополнение к простой компиляции кода. Однако большинство из этих вещей также могут быть выполнены с помощью действий до/после компиляции, которые позволяет настроить почти каждая современная IDE.
По правде говоря, если у вас нет большого количества разработчиков, вносящих обязательства в вашу систему контроля исходных текстов, или если у вас много систем или приложений, полагающихся на общие библиотеки и нуждающихся в CI, использование сценария сборки, вероятно, излишне по сравнению с более простыми альтернативами. Но если вы находитесь в одной из вышеупомянутых ситуаций, выделенный сервер сборки, который берет данные из системы контроля исходных кодов и выполняет автоматические сборки, должен стать важной частью арсенала вашей команды, и самый простой способ настроить его - использовать make, MSBuild, Ant и т.д.
Допустим, у вас есть 5 человек, работающих над одним и тем же набором кода. Каждый из этих 5 человек обновляет один и тот же набор файлов. Теперь вы можете нажать кнопку сборки и знать, что ваш код работает, но как насчет того, чтобы интегрировать его со всеми остальными? Единственное, что вы будете знать, это то, что если вы соберете все остальные и попробуете. Время от времени это легко, но быстро становится утомительно делать это снова и снова.
С сервером сборки, который делает это автоматически, он постоянно проверяет, компилируется ли код для всех. Все всегда знают, что не так со сборкой и в чем проблема, и никому не нужно работать, чтобы в этом разобраться. Небольшие вещи складываются, может потребоваться пара минут, чтобы загрузить последний код и попытаться его скомпилировать, но выполнение этого 10-20 раз в день быстро становится пустой тратой времени, особенно если этим занимается несколько человек. Конечно, вы можете обойтись и без этого, но гораздо проще позволить автоматизированному процессу делать одно и то же снова и снова, а затем сделать это реальным человеком.
Вот еще одна крутая штука. Наш процесс также настроен для тестирования всех сценариев sql. Не могу этого сделать, нажав кнопку сборки. Он перезагружает моментальные снимки всех баз данных, к которым необходимо применить исправления, и запускает их, чтобы убедиться, что все они работают и работают в нужном порядке. Сервер сборки также достаточно умен, чтобы запускать все модульные тесты / тесты автоматизации и возвращать результаты.Убедиться, что он может компилироваться, - это нормально, но с сервером автоматизации он может автоматически обрабатывать множество шагов, на которые у человека может уйти час.
Если пойти дальше, если у вас есть автоматизированный процесс развертывания вместе с сервером сборки, развертывание будет автоматическим. Любой, кто может нажать кнопку, чтобы запустить процесс и развернуть, может перенести код в qa или production. Это означает, что программисту не нужно тратить время на выполнение этого вручную, что чревато ошибками. Когда у нас не было процесса, это всегда было дерьмом, будет ли все установлено правильно, и обычно это должен был делать сетевой администратор или программист, потому что они должны были знать, как настраивать IIS и переместите файлы. Теперь даже самый младший специалист по контролю за качеством может обновить сервер, потому что все, что им нужно знать, это то, какую кнопку нажимать.
Если у вас есть автономный процесс сборки с непрерывной интеграцией, он будет управляться Ant или скриптом в стиле make. Ваш процесс CI будет проверять код вне контроля версий, когда изменения обнаруживаются на отдельной машине сборки, компилировать, тестировать, упаковывать, развертывать и создавать сводный отчет.
системы сборки IDE, которые я использовал, можно использовать из таких вещей, как инструменты Automated Build / CI, поэтому нет необходимости иметь отдельный сценарий сборки как таковой.
Однако поверх этой системы сборки вам нужно автоматизировать тестирование, управление версиями, тегирование системы управления версиями,и развертывание (и все остальное, что вам нужно для выпуска вашего продукта).
Таким образом, вы создаете сценарии, которые расширяют сборку вашей IDE и выполняют дополнительные действия.
Одна практическая причина, по которой описания сборок под управлением IDE не всегда идеальны, связана с контролем версий и необходимостью интеграции с изменениями, внесенными другими разработчиками (например, слияние).
Если ваша среда IDE использует один плоский файл, может быть очень сложно (если вообще возможно) объединить два файла проекта в один. Он может использовать текстовый формат, такой как XML, но XML, как известно, сложен со стандартными инструментами сравнения / слияния. Тот факт, что люди используют графический интерфейс для внесения изменений, повышает вероятность того, что вы внесете ненужные изменения в файлы проекта.
Распределенные сценарии сборки меньшего размера (файлы CMake, Makefile и т. Д.) Могут упростить согласование изменений в структуре проекта, как если бы вы объединяли два исходных файла. По этой причине некоторые люди предпочитают создание проектов IDE (например, с использованием CMake), даже если все работают с одними и теми же инструментами на одной платформе.