Модульная сборка проектовgears - минимальный менеджер зависимостей
Interlabs
20 августа 2014
1 / 22
Что мы хотим?
Единообразный подход к модульной сборке проектов:
• серверные модули на PHP• клиентские модули на JavaScript• стандартные таблицы стилей• фрагменты схем БД и т.д.
Для каждого типа модулей есть стандартные утилиты, можетиспользовать их?
2 / 22
Стандартные утилиты
Composer, Bower, Volo, Jam и т.д.
• ориентация на централизованные внешние реестры иgithub (большинство)
• сложность настройки частных репозиториев («вампонадобится CouchDB. . . » what??)
• невозможность использования ссылок наразрабатываемые модули (например, нет аналога npmlinks в composer)
• установка полной копии, избыточной для runtime (bower)• слишком много конфигурации
3 / 22
Наши потребности
• установка необходимого runtime-кода в проект• версионность, учет зависимостей• единое решение для серверных и клиентских модулей• адаптация под используемый нами инструментарий• возможность установки в проект произвольной структуры• гарантированная совместимость компонент между собой• минимум конфигурации
4 / 22
Что нам не важно
• взаимодействие со сторонними разработчиками(внутренняя платформа)
• интеграция с github• установка по сети — некритично, достаточно локальнойдоступности на сервере разработки
• избыточная конфигурируемость — лучше convention overconfiguration
• buzzword compatibility — нам ехать, а не шашечки
5 / 22
gears
• стандартный git-репозиторий используемых модулей• каждый модуль содержит только код, необходимый вruntime или для сборки runtime
• файлы модуля — подмножество файлов соответствующегопроекта, разработка модуля — в отдельном репозитории
• каждый модуль имеет версию, репозиторий определяетзависимости между версиями
• утилита командной строки для установки модулей сзависимостями
• использование симлинков при установке модулей в проект
6 / 22
Структура модуля
Метаданные:
package - краткое описание модуляmanifest - перечень устанавливаемых в проект файловLICENSE - текст лицензии модуляREADME.md - описание модуля
Каталоги с устанавливаемыми файлами:
js/ - модули JavaScriptcss/ - css, less или stylimg/ - стандартные изображенияtpl/ - PHP-шаблоныlib/ - PHP-классыfnt/ - шрифты
7 / 22
Версионность модулейКаждому модулю соответствует символическое имя:
jquery jquery-cycle2 bare
У каждого модуля есть версия:
jquery-1.11.1 jquery-cycle2-2.1.5 bare-0.2.0
Версия платформы устанавливает зависимости междуверсиями модулей:
jquery-cycle2: jquery jquery-cycle2-2.1.5jquery: jquery-1.11.1
8 / 22
Версионность платформы
• версия платформы определяется индекс-файлом,описывающим зависимости
• внутри одной версии платформы модули гарантированносовместимы
• появление новой версии платформы не отменяетсуществование предыдущих
• версия платформы может быть удалена, если не осталосьпроектов, использующих эту версию
• переход проекта на новую версию может потребоватьвнесение изменений в проект
9 / 22
Структура репозитория
.git/ git-репозиторийgears выполняемый файлpkg/
index-current.mk -> index-0.1.0.mk индекс по умолчаниюindex-0.1.0.mk индекс 0.1.0jquery-1.11.1/ модуль jquery
LICENSEmanifestpackageREADME.mdjs/
jquery.js устанавливаемый файлjquery-cycle2-2.1.5 плагин cycle2...
10 / 22
Требования к установкеМодули могут быть установлены в произвольный проект,поэтому:
• структура модуля не должна зависеть от структуры проекта• смена версии модуля не должна влиять на егоподключение в проекте
• модули могут быть легко переустановлены илиустановлены с нуля
• файлы модулей можно легко исключить из контроляверсий проекта, если это необходимо
• пути не должны зависеть от версий модулей
11 / 22
Установка в проект
• все модули устанавливаются в специальный выделенныйкаталог ext
• на файлы модулей создаются симлинки в других каталогахпроекта
• имя подкаталога модуля соответствует его полному именис номером версии
• симлинки в подкаталогах проекта — через промежуточныйсимлинк, соответствующий чистому имени модуля безверсии
12 / 22
Структура файлов проектаsrc/
js/jquery.js -> ../../ext/jquery/js/jquery.js
ext/jquery -> jquery-1.11.1/jquery-1.11.1/
js/jquery.js
font-pt-sans -> font-pt-sans-1.0.0font-pt-sans-1.0.0/
fnt/pt-sans-r400.eot...
www/fnt/
pt-sans -> ../../../ext/font-pt-sans/fnt
13 / 22
Установка в проект• используемые версии компонентов легко контролировать• промежуточный симлинк позволяет менять версию модулябез изменения симлинков в проекте
• для одновременной разработки модуля вместе с проектомможно использовать временный симлинк наразрабатываемую версию
• можно использовать PHP autoloader прямо из ext
А не слишком много симлинков?
• практически не влияют на производительность• симлинки в src не используются в runtime
14 / 22
Клиентские модулиПочему просто не использовать bower? Избыточность файлов иотсутствие адаптации под наши условия.
Адаптация:
• преобразование в формат AMD• исправление ошибок и реализация недостающегофункционала
• преобразование CSS в Stylus для параметризации ивключения в общую цепочку генерации CSS
• всегда включаем полную версию, минимизациявыполняется в проекте при сборке
• включаем только то, что необходимо в runtime
15 / 22
Серверные модули
Почему просто не использовать composer? Слишком многотелодвижений и сложность одновременной разработки модуляи проекта.
• PHP-классы + файлы шаблонов• используем стандартные autoload.php, не нужнодополнительно конфигурировать автозагрузчик
• не используем composer для установки в проект, что неотменяет возможность его использования внутри модуля
• каталог шаблонов включается в общую иерархиюшаблонов проекта
16 / 22
Серверные, клиентские . . .
Просто модули
• модуль может включать в себя файлы как для серверной,так и для клиентской части
• модуль — просто набор файлов, устанавливаемых постандартным правилам
17 / 22
Автоматизация установки# Установка из версии платформы current$ gears install jquery-cycle2 flight d3
# Установка из версии платформы 0.1.0$ GEARS_VERSION=0.1.0 gears install flight d3
# Автоматическая установка с помощью make.PHONY extexport GEARS_VERSION=0.1.0 # декларируем версию платформыDEPS=flight d3ext:
gears install $(DEPS)
make ext18 / 22
Использование репозитория
• должен ли проект строиться только из модулейрепозитория — нет
• накладывает ли использование репозитория ограниченияна структуру проекта — нет
• можно ли использовать непосредственно ссылки намодули репозитория — нет, за исключением случаевотладки
• должен ли ext включаться в git-репозиторий проекта —зависит от ситуации, можно не включать, еслинеобходимые модули могут быть установленыавтоматически
19 / 22
Поддержка репозитория
• необходимо периодически отслеживать новые версиимодулей сторонних разработчиков — да
• необходимо проверять совместимость новых версий врамках платформы — да
• кто поддерживает репозиторий — менеджер репозитория(один-два выделенных разработчика)
• когда — по необходимости + периодически (например,каждый месяц)
• новые модули — по запросу разработчиков проектов ибиблиотек
20 / 22
Что выигрываем
• переходим от разрозненных библиотек к единойкорпоративной платформе
• минимизируем зоопарк версий в проектах• стараемся использовать компоненты не из репозиториятолько если это действительно необходимо
• решаемые задачи относительно типовые — со временемрепозиторий перестает расти и содержит наборпроверенных типовых компонент
• максимально простая организация — не зависит отособенностей развития внешних инструментов
21 / 22
gearsprivate: https://bitbucket.org/interlabs/gears
22 / 22