Каковы преимущества сборочных скриптов?

Большую часть своей карьеры программиста я использовал команду «build / compile / run» в любой IDE, с которой я работаю, для создания работающей программы. Это одна кнопка, довольно просто. Однако по мере того, как я узнаю больше о разных языках и фреймворках, я все больше и больше говорю о «сценариях сборки» (ANT, Maven, Gradle и т. Д.) Для запуска проекта. Насколько я понимаю, они являются инструкциями для компилятора / компоновщика / создателя магических программ, которые определяют детали конфигурации - подробности.

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

Я не могу избавиться от ощущения, что сборочные сценарии важны для понимания как разработчика, но я хотел бы получить содержательное объяснение; почему я должен использовать / писать сценарии сборки?

Обязанности Build Script и Build Server обсуждают роль, которую он играет в более широком контексте. Я ищу конкретные преимущества, предоставляемые сценарием сборки, по сравнению с командой IDE "build / run" или аналогичными простыми методами.

Автоматизация.

Когда вы разрабатываете, только в самых простых проектах кнопка «сборки» по умолчанию делает все, что вам нужно; вам может потребоваться создать WS из API, сгенерировать документы, связать с внешними ресурсами, развернуть изменения на сервере и т. д. Некоторые IDE позволяют настраивать процесс сборки, добавляя дополнительные шаги или компоновщики, но это означает, что вы генерация скрипта сборки через товары IDE.

Но разработка системы - это не только написание кода. Есть несколько этапов. Независимый от IDE сценарий может выполняться автоматически, что означает, что:

• Когда вы фиксируете изменение в управлении версиями, новая сборка может запускаться сервером автоматически. Это гарантирует, что вы не забыли зафиксировать все необходимое для сборки.

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

• Теперь у остальной части организации (QA, sysadmins) есть встроенный продукт, который

  а) отлично воспроизводится только из контрольной версии.

  б) является общим для всех из них.

Даже когда я работал в одной команде, я использовал сценарии для этой цели; Когда я разработал исправление, я передал бы SVN, экспортировал SVN обратно в другой каталог и использовал сценарий сборки для генерации решения, которое затем перешло бы в системы Preproduction, а затем в Production. Если несколько недель спустя (с уже измененной моей локальной кодовой базой) кто-то жаловался на ошибку, я бы точно знал, какую версию SVN мне нужно будет проверить, чтобы правильно отладить систему.

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

Напротив, нас, наполненных водой, плотских сумок просто презренно, когда дело доходит до следующих шагов. Этот надоедливый аналитический мозг имеет тенденцию подвергать сомнению все, с чем сталкивается. «О ... Мне это не нужно» или «Действительно ли я использую этот флаг? Э… я просто проигнорирую его». Кроме того, у нас есть склонность к самоуспокоенности. Как только мы что-то сделали несколько раз, мы начинаем верить, что знаем инструкции, и нам не нужно смотреть лист инструкции.

От "Прагматичного Программиста":

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

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

Я приведу пример из реальной жизни. Я работал над некоторым встроенным программным обеспечением, где большая часть кода была распределена между несколькими аппаратными платформами. У каждой платформы было разное оборудование, но большая часть программного обеспечения была одинаковой. Но были маленькие кусочки, которые были характерны для каждого оборудования. В идеале, общие части должны быть помещены в библиотеку и связаны с каждой версией. Тем не менее, общие части не могут быть скомпилированы в общую библиотеку. Это должно было быть скомпилировано с каждой другой конфигурацией.

Сначала я вручную компилировал каждую конфигурацию. Переключение между конфигурациями заняло всего несколько секунд, и это было не так уж сложно. К концу проекта в общей части кода был обнаружен критический дефект, когда устройство по существу захватило коммуникационную шину. Это было плохо! Действительно плохо. Я нашел ошибку в коде, исправил ее и перекомпилировал каждую версию. Кроме одного. В процессе сборки я отвлекся и забыл одну. Двоичные файлы были освобождены, машина была собрана, и через день мне позвонили и сказали, что машина перестала отвечать. Я проверил это и обнаружил, что устройство заблокировало автобус. «Но я исправил эту ошибку!».

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

Если все, что вы когда-либо хотели сделать, - это то <compiler> **/*.<extension>, что скрипты сборки не имеют особой цели (хотя можно утверждать, что, если вы видите Makefileв проекте, вы знаете, что вы можете собрать его с помощью make). Дело в том, что нетривиальные проекты обычно требуют большего, по крайней мере, вам обычно нужно добавлять библиотеки и (по мере развития проекта) настраивать параметры сборки.

Среды IDE обычно, по крайней мере, настраиваются, но теперь процесс сборки опирается на параметры, специфичные для среды IDE. Если вы используете Eclipse , Алиса предпочитает NetBeans , а Боб хочет использовать IntelliJ IDEA , вы не можете поделиться конфигурацией, и когда один из вас вносит изменение в элемент управления исходным кодом, ему нужно либо вручную отредактировать созданную IDE конфигурацию. файлы других разработчиков, или уведомите других разработчиков, чтобы они сделали это сами (что означает, что будут коммиты, где конфигурация IDE является неправильной для некоторых IDE ...).

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

Теперь эта проблема зависит от культуры - ваши разработчики могут посчитать приемлемым отсутствие выбора IDE. Но разработчики, имеющие опыт работы с IDE, обычно более счастливы и эффективны при ее использовании, а пользователи текстовых редакторов склонны проявлять религиозный фанатизм в отношении своих любимых инструментов, поэтому это одно из мест, где вы хотите дать разработчикам свободу. - и строить системы позволяют вам сделать это. У некоторых людей может быть предпочтение в системе сборки, но это не так фанатично, как в настройках IDE / редактора ...

Даже если вы заставите всех разработчиков использовать одну и ту же среду IDE - удачи в том, чтобы убедить сервер сборки использовать ее ...

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

Наконец, сборка систем полезна не только для построения проекта - вы можете запрограммировать их для выполнения других задач, которые могут понадобиться всем в команде. В Ruby On Rails , например, есть строить системные задачи для выполнения миграции базы данных, для очистки временных файлов и т.д. Ввод этих задач в системе сборки гарантирует , что каждый член команды может сделать их последовательно.

Многие IDE просто упаковывают команды, используемые для создания чего-либо, а затем генерируют скрипт и вызывают его!

Например, в Visual Studio вы можете увидеть параметры командной строки для компиляции C ++ в поле «командная строка». Если вы внимательно посмотрите на выходные данные сборки, вы увидите временный файл, содержащий скрипт сборки, который использовался для запуска компиляции.

В настоящее время это все MSBuild , но он все еще выполняется непосредственно IDE.

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

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

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

make

намного легче запомнить и напечатать, чем

gcc -o myapp -I/include/this/dir -I/include/here/as/well -I/dont/forget/this/one src/myapp.c src/myapp.h src/things/*.c src/things/*.h

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

make clean

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

Конечно, если вы используете IDE, то тоже легко нажать кнопку сборки или очистки. Однако гораздо сложнее автоматизировать перемещение курсора в определенное место на экране, особенно когда это место может перемещаться при перемещении окна, чем автоматизировать простую текстовую команду.

Как еще ты это сделаешь? Единственный другой способ - указать одну длинную команду командной строки.

Другая причина в том, что make-файлы допускают пошаговую компиляцию, что значительно ускоряет время компиляции.

Makefiles также может сделать процесс сборки кроссплатформенным. CMake генерирует различные сценарии сборки на основе платформы.

Редактировать:

С IDE вы привязаны к определенному способу ведения дел. Многие люди используют vim или emacs, хотя у них не так много IDE-подобных функций. Они делают это, потому что они хотят власти, которую предоставляют эти редакторы. Скрипты сборки необходимы для тех, кто не использует IDE.

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

Сами IDE также часто создают сценарии для внутреннего использования; Кнопка запуска - это еще один способ запуска команды make.

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

Я профессиональный разработчик Android / IOS / Windows Phone, и я использую API - интерфейсы сервисов Google ( в основном Google Maps) на много .

В Android эти службы требуют, чтобы я добавил в консоль разработчика хранилище ключей или тип файла идентификатора разработчика, который сообщает Google, что я являюсь тем, кем я говорю. Если мое приложение скомпилировано с другим хранилищем ключей, раздел Google Maps приложения не будет работать.

Вместо добавления дюжины хранилищ ключей в консоль разработчика и управления ими, в любом случае для обновления приложения можно использовать только один, я включаю это хранилище ключей в наше безопасное хранилище и использую Gradle, чтобы сообщить Android Studio, какое хранилище ключей использовать при сборке для «отладка» или «выпуск». Теперь мне нужно только добавить два хранилища ключей в мою консоль разработчика Google, один для «отладки» и один для «выпуска», и все члены моей команды могут клонировать репозиторий и получить право на разработку, не прибегая к помощи разработчика. консоль и добавьте хэш SHA их конкретного хранилища ключей, или, что еще хуже, заставьте меня управлять ими, Это дает дополнительное преимущество, предоставляя каждому члену команды копию хранилища ключей для подписи, а это означает, что если я нахожусь вне офиса и запланировано обновление, члену команды нужно только следовать очень короткому списку инструкций, чтобы подтолкнуть Обновить.

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

Преимущества скрипта сборки:

• изменения выглядят как код (например, в команде git diff), а не как разные отмеченные опции в диалоге

• создавая больше продукции, чем простая сборка

В некоторых из моих предыдущих проектов я использовал сценарии сборки для:

• генерировать проектную документацию (на основе кислорода)
• строить
• запустить юнит-тесты
• создавать отчеты о покрытии модульных тестов
• упаковать двоичные файлы в архив релизов
• генерировать внутренние заметки о выпуске (на основе сообщений "git log")
• автоматизированное тестирование

Часто вы можете вызывать кнопку «сборки» автоматически (например, Visual Studio принимает аргументы командной строки). Люди пишут сценарии сборки, как только им нужно что-то, чего не может предоставить кнопка сборки.

Например, большинство IDE позволяют вам создавать только одну платформу за раз. Или только один язык за раз. Тогда есть то, что вы делаете со встроенными выходами: может ли ваша IDE свернуть их все в установочный пакет?