Автоматизация сборки

Автоматизация сборки — программные комплексы, автоматически исполняющие различные этапы по превращению человекоредактируемых исходных файлов в готовую программу, в частности:

  • компиляция исходного кода в объектный модуль;
  • сборка бинарного кода в исполняемый файл;
  • сбор и передача информации итоговой программе (версия программы, системы, компилятора, аппаратная информация, системная информация, лицензия программы, имя автора и т. п.);
  • подготовка файлов данных — часто также «компилируемых» особыми программами;
  • сборка рабочего каталога программы, включающего главный исполняемый файл, чужие программные модули, файлы данных, файлы конфигурации;
  • упаковка этого каталога в готовый дистрибутив;
  • развёртывание программы в целевой среде;
  • выполнение тестов;
  • генерация сопроводительной документации или описание изменений новой версии;
  • если программу можно собрать разными способами (на разных ОС и компиляторах, с разными файлами данных или системными библиотеками, с разной включённой функциональностью) — поддержка таковых. Так, cURL может быть автономной программой, статической или динамической библиотекой, на разных библиотеках TLS, с поддержкой юникодных доменов и нет…

Основное средство автоматизации сборки — применение специализированного инструмента; один из ранних и исторически значимых инструментов является утилита make, во многом определившая стиль и методы для инструментов, появившихся позднее[⇨]. Один из таких элементов — формат Makefile, поддерживаемый в большинстве широко используемых инструментов (Automake, CMake, imake, qmake, nmake, wmake, Apache Ant, Apache Maven, OpenMake Meister, Gradle). Ключевые требования, предъявляемые средствам автоматизации — поддержка технологий непрерывной интеграции, в частности, постоянных «ночных сборок»[1][2][3], управление зависимостями исходного кода, обеспечение разностной сборки, уведомление при совпадении исходного кода (после сборки) с имеющимися двоичными файлами, предоставление удобных отчётов о результатах компиляции и компоновки, автоматический запуск тестов и условное выполнение в зависимости от результатов прохождения.

Виды автоматизации, применяемые в различных инструментах:

Двухуровневая сборка

править

Автоматизация сборки часто двухуровневая, состоящая из двух программ:

  • Нижний уровень — непосредственно занимается запуском компиляторов, знает, где они в структуре каталогов данной ОС, и как файлы зависят друг от друга. Примеры: Make, Ninja.
  • Верхний уровень — понимает специфику языка программирования, оперирует высокоуровневыми понятиями «путь для заголовочных файлов», «определения символов» и другими. Примеры: QMake, CMake.

Более высокие уровни могут включать запуск сборки по сети или по таймеру, «компиляцию» файлов данных, исполнение тестов и прочее. Традиционное решение — командный файл, стандартом также стал Python, одинаковый для всех ОС.

История

править

Исторически так сложилось, что разработчики применяли автоматизацию сборки для вызова компиляторов и компоновщиков из сценария сборки, в отличие от вызова компилятора из командной строки. Довольно просто при помощи командной строки передать один исходный модуль компилятору, а затем и компоновщику для создания конечного объекта. Однако, при попытке скомпилировать или скомпоновать множество модулей с исходным кодом, причём в определённом порядке, осуществление этого процесса вручную при помощи командной строки выглядит слишком неудобным. Гораздо более привлекательной альтернативой является сценарный язык, поддерживаемый утилитой Make. Данный инструмент позволяет писать скрипты сборки, определяя порядок их вызова, этапы компиляции и компоновки для сборки программы. GNU Make[4] также предоставляет такие дополнительные возможности, как например, «зависимости» («makedepend»), которые позволяют указать условия подключения исходного кода на каждом этапе сборки. Это и стало началом автоматизации сборки. Основной целью была автоматизация вызовов компиляторов и компоновщиков. По мере роста и усложнения процесса сборки разработчики начали добавлять действия до и после вызовов компиляторов, как например, проверку (англ. check-out) версий копируемых объектов на тестовую систему. Термин «автоматизация сборки» уже включает управление и действия до и после компиляции и компоновки, также как и действия при компиляции и компоновке.

В 2000-е годы решения по управлению сборкой сделали ещё более удобным и управляемым процесс автоматизированной сборки. Для выполнения автоматизированной сборки и контроля этого процесса существуют как коммерческие, так и открытые решения. Некоторые решения нацелены на автоматизацию шагов до и после вызова сборочных скриптов, а другие выходят за рамки действий до и после обработки скриптов и полностью автоматизируют процесс компиляции и компоновки, избавляя от ручного написания сценариев. Такие инструменты полезны для непрерывной интеграции, когда требуются частые вызовы компиляции и обработка промежуточных сборок.

Распределённая сборка

править

Распределённая сборка подразумевает, что вызовы компилятора и компоновщика могут передаваться множеству компьютеров для ускорения сборки. Распределённый процесс сборки должен обладать определённой логикой, чтобы правильно определить зависимости в исходном коде для того чтобы выполнить этапы компиляции и компоновки на разных машинах. Решение автоматизации сборки должно быть способно управлять этими зависимостями, чтобы выполнять распределённые сборки. Некоторые инструменты сборки могут распознавать подобные взаимосвязи автоматически (Rational ClearMake distributed[5], Electric Cloud ElectricAccelerator[6]), а другие зависят от пользовательских указаний (Platform LSF lsmake[7]). Автоматизация сборки, способная рассортировывать взаимосвязи зависимостей исходного кода, также может быть настроена на выполнение действий компиляции и компоновки в режиме параллельного выполнения. Это означает, что компиляторы и компоновщики могут быть вызваны в многопоточном режиме на машине, сконфигурированной с учётом наличия более одного процессорного ядра.

Не все инструменты автоматизации сборки могут выполнять распределённые сборки. Большинство из них лишь реализует поддержку распределённой обработки (то есть посылать задачи на выполнение различных сценариев на разные машины, например, на этап после выполнения множества тестовых сценариев). Кроме того, большинство решений, поддерживающих распределённые сборки, могут лишь обрабатывать код на языках Си и C++. Решения автоматизации сборки, поддерживающие распределённую обработку, зачастую основаны на Make и не поддерживают Maven или Ant.

В качестве примера решения распределённой сборки можно привести Xoreax’s IncrediBuild[8] для платформы Microsoft Visual Studio. Это может потребовать специфической настройки программного окружения чтобы успешно функционировать на распределённой платформе (нужно указать расположение библиотек, переменные окружения и так далее).

Примечания

править
  1. Build and Release Management | freshmeat.net Архивировано 30 сентября 2007 года.
  2. IBM developerWorks: Site maintenance. Дата обращения: 4 октября 2009. Архивировано 2 марта 2009 года.
  3. Buildbot. Дата обращения: 4 октября 2009. Архивировано из оригинала 6 декабря 2010 года.
  4. GNU Make — GNU Project — Free Software Foundation (FSF). Дата обращения: 4 октября 2009. Архивировано 5 июля 2006 года.
  5. Dr. Dobb's Distributed Loadbuilds, Дата обращения: 13 апреля 2009
  6. Dr. Dobb's Take My Build, Please
  7. LSF User's Guide - Using lsmake, Архивировано из оригинала 7 октября 2007, Дата обращения: 13 апреля 2009 Источник. Дата обращения: 4 октября 2009. Архивировано из оригинала 7 октября 2007 года.
  8. Distributed Visual Studio Builds, Архивировано 12 апреля 2009, Дата обращения: 8 апреля 2009 Источник. Дата обращения: 4 октября 2009. Архивировано 12 апреля 2009 года.

Литература

править