Модульная сборка проектов
Upcoming SlideShare
Loading in...5
×
 

Модульная сборка проектов

on

  • 179 views

Слайды к обсуждению подхода к сборке проектов из стандартных библиотечных модулей, внедряемого в компании.

Слайды к обсуждению подхода к сборке проектов из стандартных библиотечных модулей, внедряемого в компании.

Statistics

Views

Total Views
179
Views on SlideShare
177
Embed Views
2

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 2

http://www.slideee.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Модульная сборка проектов Модульная сборка проектов Presentation Transcript

  • Модульная сборка проектов gears - минимальный менеджер зависимостей Interlabs 20 августа 2014 1 / 22
  • Что мы хотим? Единообразный подход к модульной сборке проектов: • серверные модули на PHP • клиентские модули на JavaScript • стандартные таблицы стилей • фрагменты схем БД и т.д. Для каждого типа модулей есть стандартные утилиты, может использовать их? 2 / 22
  • Стандартные утилиты Composer, Bower, Volo, Jam и т.д. • ориентация на централизованные внешние реестры и github (большинство) • сложность настройки частных репозиториев («вам понадобится CouchDB...» what??) • невозможность использования ссылок на разрабатываемые модули (например, нет аналога npm links в composer) • установка полной копии, избыточной для runtime (bower) • слишком много конфигурации 3 / 22
  • Наши потребности • установка необходимого runtime-кода в проект • версионность, учет зависимостей • единое решение для серверных и клиентских модулей • адаптация под используемый нами инструментарий • возможность установки в проект произвольной структуры • гарантированная совместимость компонент между собой • минимум конфигурации 4 / 22
  • Что нам не важно • взаимодействие со сторонними разработчиками (внутренняя платформа) • интеграция с github • установка по сети — некритично, достаточно локальной доступности на сервере разработки • избыточная конфигурируемость — лучше convention over configuration • buzzword compatibility — нам ехать, а не шашечки 5 / 22
  • gears • стандартный git-репозиторий используемых модулей • каждый модуль содержит только код, необходимый в runtime или для сборки runtime • файлы модуля — подмножество файлов соответствующего проекта, разработка модуля — в отдельном репозитории • каждый модуль имеет версию, репозиторий определяет зависимости между версиями • утилита командной строки для установки модулей с зависимостями • использование симлинков при установке модулей в проект 6 / 22
  • Структура модуля Метаданные: package - краткое описание модуля manifest - перечень устанавливаемых в проект файлов LICENSE - текст лицензии модуля README.md - описание модуля Каталоги с устанавливаемыми файлами: js/ - модули JavaScript css/ - css, less или styl img/ - стандартные изображения 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.5 jquery: 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.0 jquery-1.11.1/ модуль jquery LICENSE manifest package README.md js/ 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.0 font-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 ext export GEARS_VERSION=0.1.0 # декларируем версию платформы DEPS=flight d3 ext: gears install $(DEPS) make ext 18 / 22
  • Использование репозитория • должен ли проект строиться только из модулей репозитория — нет • накладывает ли использование репозитория ограничения на структуру проекта — нет • можно ли использовать непосредственно ссылки на модули репозитория — нет, за исключением случаев отладки • должен ли ext включаться в git-репозиторий проекта — зависит от ситуации, можно не включать, если необходимые модули могут быть установлены автоматически 19 / 22
  • Поддержка репозитория • необходимо периодически отслеживать новые версии модулей сторонних разработчиков — да • необходимо проверять совместимость новых версий в рамках платформы — да • кто поддерживает репозиторий — менеджер репозитория (один-два выделенных разработчика) • когда — по необходимости + периодически (например, каждый месяц) • новые модули — по запросу разработчиков проектов и библиотек 20 / 22
  • Что выигрываем • переходим от разрозненных библиотек к единой корпоративной платформе • минимизируем зоопарк версий в проектах • стараемся использовать компоненты не из репозитория только если это действительно необходимо • решаемые задачи относительно типовые — со временем репозиторий перестает расти и содержит набор проверенных типовых компонент • максимально простая организация — не зависит от особенностей развития внешних инструментов 21 / 22
  • gears private: https://bitbucket.org/interlabs/gears 22 / 22