Автоматизация сборки
Автоматизация сборки — этап процесса разработки программного обеспечения, заключающийся в автоматизации широкого спектра задач, решаемых программистами в их повседневной деятельности.
Включает такие действия, как:
- компиляция исходного кода в объектный модуль,
- сборка бинарного кода в исполняемый файл,
- выполнение тестов,
- развёртывание программы в целевой среде,
- Написание сопроводительной документации или описание изменений новой версии,
- Конфигурация и подготовка файлов к сборке,
- Сбор и передача информации итоговой программе (версия программы, системы, компилятора, аппаратная информация, системная информация, лицензия программы, имя автора и т. п.).
Основное средство автоматизации сборки — применение специализированного инструмента; один из ранних и исторически значимых инструментов является утилита
, управление зависимостями исходного кода, обеспечение разностной сборки, уведомление при совпадении исходного кода (после сборки) с имеющимися двоичными файлами, предоставление удобных отчётов о результатах компиляции и компоновки, автоматический запуск тестов и условное выполнение в зависимости от результатов прохождения.Виды автоматизации, применяемые в различных инструментах:
- автоматизация по запросу (on-demand automation): запуск пользователем командной строке,
- запланированная автоматизация (scheduled automation): ночных сборок,
- условная автоматизация (triggered automation): непрерывная интеграция, выполняющая сборку при каждом подтверждении изменения кода (commit) в системе управления версиями.
История
Исторически так сложилось, что разработчики применяли автоматизацию сборки для вызова компиляторов и компоновщиков из сценария сборки, в отличие от вызова компилятора из
В 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, Дата обращения: 13 апреля 2009
- ↑ Dr. Dobb's Take My Build, Please
- ↑ LSF User's Guide - Using lsmake, Архивировано из оригинала 7 октября 2007, Дата обращения: 13 апреля 2009 Источник . Дата обращения: 4 октября 2009. Архивировано из оригинала 7 октября 2007 года.
- ↑ Distributed Visual Studio Builds, Архивировано 12 апреля 2009, Дата обращения: 8 апреля 2009 Источник . Дата обращения: 4 октября 2009. Архивировано 12 апреля 2009 года.
Литература
- Майк Кларк: Pragmatic Project Automation, The Pragmatic Programmers ISBN 0-9745140-3-9
- Capacity Planning
Для улучшения этой статьи желательно:
|