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

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

Включает такие действия, как:

компиляция исходного кода в объектный модуль,
сборка бинарного кода в исполняемый файл,
выполнение тестов,
развёртывание программы в целевой среде,
Написание сопроводительной документации или описание изменений новой версии,
Конфигурация и подготовка файлов к сборке,
Сбор и передача информации итоговой программе (версия программы, системы, компилятора, аппаратная информация, системная информация, лицензия программы, имя автора и т. п.).

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

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

автоматизация по запросу (on-demand automation): запуск пользователем сценария в командной строке,
запланированная автоматизация (scheduled automation): непрерывная интеграция, происходящая в виде ночных сборок,
условная автоматизация (triggered automation): непрерывная интеграция, выполняющая сборку при каждом подтверждении изменения кода (commit) в системе управления версиями.

История

Исторически так сложилось, что разработчики применяли автоматизацию сборки для вызова компиляторов и компоновщиков из сценария сборки, в отличие от вызова компилятора из командной строки. Довольно просто при помощи командной строки передать один исходный модуль компилятору, а затем и компоновщику для создания конечного объекта. Однако, при попытке скомпилировать или скомпоновать множество модулей с исходным кодом, причём в определённом порядке, осуществление этого процесса вручную при помощи командной строки выглядит слишком неудобным. Гораздо более привлекательной альтернативой является сценарный язык, поддерживаемый утилитой 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. Это может потребовать специфической настройки программного окружения чтобы успешно функционировать на распределённой платформе (нужно указать расположение библиотек, переменные окружения и так далее).

Примечания

↑ Build and Release Management | freshmeat.net Архивировано 30 сентября 2007 года.
↑ IBM developerWorks: Site maintenance (неопр.). Дата обращения: 4 октября 2009. Архивировано 2 марта 2009 года.
↑ Buildbot (неопр.) (недоступная ссылка). Дата обращения: 4 октября 2009. Архивировано 6 декабря 2010 года.
↑ GNU Make — GNU Project — Free Software Foundation (FSF) (неопр.). Дата обращения: 4 октября 2009. Архивировано 5 июля 2006 года.
↑ Dr. Dobb's Distributed Loadbuilds, <http://www.ddj.com/architect/184405385>. Проверено 13 апреля 2009.
↑ Dr. Dobb's Take My Build, Please, <http://www.ddj.com/architect/184415472>
↑ LSF User's Guide - Using lsmake, <http://www.lle.rochester.edu/pub/support/lsf/10-lsmake.html>. Проверено 13 апреля 2009. Архивная копия от 7 октября 2007 на Wayback Machine
↑ Distributed Visual Studio Builds, <http://www.xoreax.com/solutions_vs.htm>. Проверено 8 апреля 2009. Архивная копия от 12 апреля 2009 на Wayback Machine

Литература

Майк Кларк: Pragmatic Project Automation, The Pragmatic Programmers ISBN 0-9745140-3-9
Capacity Planning

[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, <http://www.ddj.com/architect/184405385>. Проверено 13 апреля 2009.

[6] Dr. Dobb's Take My Build, Please, <http://www.ddj.com/architect/184415472>

[7] LSF User's Guide - Using lsmake, <http://www.lle.rochester.edu/pub/support/lsf/10-lsmake.html>. Проверено 13 апреля 2009. Архивная копия от 7 октября 2007 на Wayback Machine

[8] Distributed Visual Studio Builds, <http://www.xoreax.com/solutions_vs.htm>. Проверено 8 апреля 2009. Архивная копия от 12 апреля 2009 на Wayback Machine

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]