Что это?
Данный пост будет об автоматических системах сборки. Думаю, интуитивно понятно что это и зачем нужно, но для формальности написать нужно — это такие программные продукты, которые на основе некоторой конфигурации могут «собрать» ваш проект.
Под словом «собрать» здесь может скрываться очень обширный объем работы, который при «ручном» подходе требует значительных затрат времени.
Небольшой перечень для ясности:
- загрузить зависимые библиотеки для вашего проекта из сети (репозитория);
- скомпилировать классы модуля или всего проекта;
- сгенерировать дополнительные файлы: SQL-скрипты, XML-конфиги и т.п.;
- удалять/создавать директории и копировать в них указанные файлы;
- упаковка скомпилированных классов проекта в архивы различных форматов: zip, rar, rpm, jar, ear, war и др.;
- компиляция и запуск модульных тестов (unit-test) вашего проекта с результатами выполнения тестов и расчетом процента покрытия;
- установка (deploy) файлов проекта на удаленный сервер;
- генерация документации и отчетов.
Наиболее популярными представителями подобных систем являются Ant + Ivy, Maven.
Путаница
На хабре есть ряд статей о Maven, но, к сожалению, все они находятся в разных хабах, т.к. отдельного хаба для билд систем не существует.
Поэтому, я решил «не быть как все» и выбрать именно общий хаб «Программирование», а не «Java», «Веб-разработка» и др.
Поэтому не заинтересованный читатель может продолжить свой поиск интересного, а заинтересованный — читать далее.
Я специально начал пост с пояснений и описания возможностей, так как данные системы могут делать сборки не только для «Java» и применимы не только в веб-разработке. Возможности и варианты использования данных систем значительно шире.
В конце концов они могут даже вообще код не компилировать, но делать автоматическую рутинную работу: генерация, архивация, операции с файлами, установка на сервер — что позволяет разработчикам эффективнее тратить своё время.
High-level архитектура
Архитектура всех build-систем сводится к следующему:
- конфигурации
- собственная конфигурация, где хранятся «личные» настройки системы. Например, такие как информация о месте установки или окружении, информация о репозиториях и прочее;
- конфигурация модуля, где описывается место расположения проекта, его зависимости и задачи, которые требуется выполнять для проекта;
- парсеры конфигураций
- парсер способный «прочитать» конфигурацию самой системы, для её настройки соответствующим образом;
- парсер конфигурации модуля, где некоторыми «понятными человеку» терминами описываются задачи для системы сборки;
- сама система — некоторая утилита + скрипт для её запуска в вашей ОС, которая после чтения всех конфигураций начнет выполнять тот или иной алгоритм, необходимый для реализации запущенной задачи;
- система плагинов — дополнительные подключаемые надстройки для системы, в которых описаны алгоритмы реализации типовых задач;
- локальный репозиторий — репозиторий, расположенный на локальной машине, для кэширования запрашиваемых файлов на удаленных репозиториях.
Для людей незнакомых с терминологией: репозиторий — некоторое структурированное хранилище некоторых данных. Например, различных вспомогательных библиотек/плагинов/скриптов/документации/исходников и т.д.
На этом общую часть о build-системах закончу и перейду к более конкретным вещам.
Maven
Так как переписывать то, что написали другие было бы неправильно, поэтому приведу перечень статей по теме, которые уже есть на хабре о Maven и где описано конкретно об этой системе — что это, как работает и на каких принципах основана.
Советую читать именно в этом порядке:
- Maven — зачем? — вводная статья о Maven, где описано как устроена конфигурация модуля/проекта, жизненный цикл сборки.
- Apache Maven — основы — терминология, установка, сборка, создание проекта из архетипа, полезные ссылки
- Maven — автоматизация сборки проекта — более детальное описание жизненного цикла сборки, описание настроек диплоя (deploy), на примере установки для Tomcat сервера.
- Создание своих архетипов и каталогов в Maven — для людей уже «в теме» и желающих создавать свои архетипы, если по каким-то причинам не хватает существующих. Процесс описан довольно детально.
Заключение
Целью данной статьи было донести до читателя информацию о системах сборки в целом, зачем они нужны и какие задачи способны выполнять.
На этом откланиваюсь и надеюсь, что данная статья найдет своего читателя, который не побоится использовать подобные системы для своих повседневных задач, и покажет простоту и эффективность систем сборки проектов.
Продолжение: Build Systems — Local Repository
