Почему следует использовать систему сборки поверх той, которая входит в состав IDE?

Question

Я слышал, как несколько человек говорили, что если ваш процесс сборки нажимает кнопку сборки, ваш процесс сборки нарушается. Часто это сопровождается советами использовать такие вещи, как make, cmake, nmake, MSBuild и т. Д. Что именно предлагают эти инструменты, которые оправдывают ручное ведение отдельного файла конфигурации?

РЕДАКТИРОВАТЬ: меня больше всего интересуют ответы, которые могут относиться к одному разработчику, работающему над проектом C ++ из ~ 20 000 строк, но меня также интересует общий случай.

РЕДАКТИРОВАТЬ2: Не похоже, что есть один хороший ответ на этот вопрос, поэтому я пошел вперед и сделал его CW. В ответ на разговоры о непрерывной интеграции, да, я полностью понимаю, когда у вас есть много разработчиков в проекте с CI - это хорошо. Однако это преимущество CI, а не поддержание отдельных сценариев сборки. Они ортогональны: например, Team Foundation Build - это решение CI, использующее файлы проекта Visual Studio в качестве конфигурации.

Answer 1

Помимо потребностей в непрерывной интеграции, которые уже были учтены всеми остальными, вы также можете просто захотеть автоматизировать некоторые другие аспекты вашего процесса сборки. Может быть, это что-то простое: увеличение номера версии в производственной сборке, запуск модульных тестов, сброс и проверка тестовой среды, запуск FxCop или пользовательского сценария, который автоматизирует проверку кода на соответствие корпоративным стандартам. Сценарий сборки - это просто способ автоматизации чего-либо в дополнение к простой компиляции кода. Тем не менее, большинство этих видов вещей также может быть выполнено с помощью действий перед компиляцией / посткомпиляцией, которые позволяет настраивать почти каждая современная IDE.

По правде говоря, если у вас нет большого количества разработчиков, работающих с вашей системой управления версиями, или если у вас много систем или приложений, использующих общие библиотеки, и вам необходимо выполнять CI, использование сценария сборки, вероятно, излишне по сравнению с более простыми альтернативами. Но если вы находитесь в одной из вышеупомянутых ситуаций, выделенный сервер сборки, который использует управление исходным кодом и выполняет автоматические сборки, должен стать неотъемлемой частью арсенала вашей команды, и самый простой способ настроить его - использовать make, MSBuild, Ant и т. Д.

Answer 2

Одной из причин использования системы сборки, которую я удивлен, никто больше не упомянул, является гибкость. В прошлом я также использовал встроенную систему сборки моей IDE для компиляции своего кода. Однако я столкнулся с большой проблемой, когда IDE, которую я использовал, был прекращен. Моя способность компилировать мой код была связана с моей IDE, поэтому я был вынужден пересмотреть всю мою систему сборки. Однако во второй раз я не совершил ту же ошибку. Я реализовал свою систему сборки через make-файлы, чтобы я мог по желанию переключать компиляторы и IDE без необходимости повторной реализации системы сборки.

Я столкнулся с подобной проблемой на работе. У нас была собственная утилита, которая была построена как проект Visual Studio. Это довольно простая утилита, которая годами не нуждалась в обновлении, но недавно мы обнаружили редкую ошибку, которую нужно было исправить. К нашему ужасу, мы обнаружили, что утилита была построена с использованием версии Visual Studio, которая была на 5-6 версий старше, чем у нас есть в настоящее время. Новый VS не будет правильно читать файл проекта старой версии, и нам пришлось заново создавать проект с нуля. Даже при том, что мы все еще использовали ту же самую IDE, различия в версиях сломали нашу систему сборки.

Когда вы используете отдельную систему сборки, вы полностью контролируете ее. Изменение IDE или версий IDE ничего не сломает. Если ваша система сборки основана на инструменте с открытым исходным кодом, таком как make, вам также не нужно беспокоиться о том, что ваши инструменты сборки будут прекращены или отменены, потому что вы всегда можете пересобрать их из исходного кода (плюс исправлять ошибки), если это необходимо , Опора на систему сборки вашего IDE создает единую точку отказа (особенно на платформах, таких как Visual Studio, которые также включают в себя компилятор ), и, на мой взгляд, для меня было достаточно причины отделить мою систему сборки и IDE.

На более философском уровне я твердо верю, что нехорошо автоматизировать то, что вы не понимаете. Хорошо использовать автоматизацию, чтобы сделать себя более продуктивным, но только если у вас есть четкое понимание того, что происходит под капотом (чтобы вы не застряли, когда автоматизация сломалась, если не по какой-либо другой причине). Когда я впервые начал программировать, я использовал встроенную систему сборки своего IDE, потому что она была простой и автоматической. Позже я начал осознавать, что не совсем понимаю, что происходит, когда нажимаю кнопку «Компиляция». Я немного почитал и начал собирать простой сценарий сборки с нуля, сравнивая мой вывод с выводом системы сборки IDE. Через некоторое время я понял, что теперь у меня есть возможность делать все, что трудно или невозможно, через IDE. Настроив параметры командной строки компилятора сверх того, что предоставляла среда IDE, я смог получить меньший, немного более быстрый вывод. Что еще более важно, я стал лучшим программистом, обладая реальными знаниями всего процесса разработки от написания кода до генерации машинного языка. Понимание и контроль всего сквозного процесса позволяет мне оптимизировать и настроить его в соответствии с потребностями любого проекта, над которым я сейчас работаю.

Answer 3

системы сборки IDE, которые я использовал, все можно использовать из таких вещей, как инструменты Automated Build / CI, поэтому нет необходимости иметь отдельный скрипт сборки как таковой.

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

Таким образом, вы создаете сценарии, которые расширяют вашу сборку IDE и делают дополнения.

Answer 4

Допустим, у вас есть 5 человек, работающих над одним и тем же набором кода. Каждый из этих 5 человек обновляет один и тот же набор файлов. Теперь вы можете нажать кнопку сборки и вы знаете, что ваш код работает, но что делать, когда вы интегрируете его со всеми остальными. Единственное, что вы будете знать, это то, что если вы получите все остальные и попробуете. Это легко время от времени, но это быстро становится утомительным, чтобы делать это снова и снова.

С сервером сборки, который делает это автоматически, он проверяет, все ли время компилируется код для всех. Все всегда знают, если что-то не так со сборкой, и в чем проблема, и никто не должен делать какую-либо работу, чтобы понять это. Маленькие вещи складываются, может потребоваться пара минут, чтобы вытащить последний код и попытаться скомпилировать его, но выполнение этого 10-20 раз в день быстро становится пустой тратой времени, особенно если это делают несколько человек. Конечно, вы можете обойтись без этого, но гораздо проще позволить автоматизированному процессу делать одно и то же снова и снова, чем это делает реальный человек.

Вот еще одна крутая вещь. Наш процесс настроен для тестирования всех сценариев sql. Не могу сделать это нажатием кнопки сборки. Он перезагружает снимки всех баз данных, к которым необходимо применить исправления, и запускает их, чтобы убедиться, что все они работают и работают в том порядке, в котором они должны. Сервер сборки также достаточно умен, чтобы запускать все модульные тесты / тесты автоматизации и возвращать результаты. Хорошо убедиться, что он может скомпилироваться, но с помощью сервера автоматизации он может автоматически выполнять множество шагов, что может занять у человека, может быть, час.

Если сделать еще один шаг вперед, если у вас есть автоматизированный процесс развертывания вместе с сервером сборки, развертывание происходит автоматически. Любой, кто может нажать кнопку для запуска процесса и развертывания, может переместить код в qa или production. Это означает, что программисту не нужно тратить время на ручное управление, что подвержено ошибкам. Когда у нас не было этого процесса, это всегда был дерьмовый ход о том, все ли будет установлено правильно, и обычно это должен был делать сетевой администратор или программист, потому что они должны были знать, как настроить IIS и переместить файлы. Теперь даже наш самый младший сотрудник может обновить сервер, потому что все, что ему нужно знать, - это какую кнопку нажать.

Answer 5

Если у вас есть процесс непрерывной интеграции, то он будет управляться скриптом Ant или make-style.Процесс CI будет проверять код вне контроля версий, когда изменения обнаруживаются на отдельном компьютере сборки, компилируются, тестируются, упаковываются, развертываются и создают сводный отчет.

Answer 6

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

Если ваша IDE использует один плоский файл, может быть очень сложно (если не невозможно) объединить два файла проекта в один.Это может быть использование текстового формата, такого как XML, но XML это общеизвестно сложно с помощью стандартных инструментов сравнения / слияния.Тот факт, что люди используют GUI для редактирования, повышает вероятность того, что вы получите ненужные изменения в файлах проекта.

С распределенными небольшими сценариями сборки (файлы CMake, файлы Makefile и т. Д.),может быть проще согласовать изменения в структуре проекта так же, как если бы вы объединили два исходных файла.По этой причине некоторые люди предпочитают создание проектов IDE (например, с использованием CMake), даже если все работают с одинаковыми инструментами на одной платформе.