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

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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

286
views

Published on

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

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

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
286
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Модульная сборка проектов gears - минимальный менеджер зависимостей Interlabs 20 августа 2014 1 / 22
  • 2. Что мы хотим? Единообразный подход к модульной сборке проектов: • серверные модули на PHP • клиентские модули на JavaScript • стандартные таблицы стилей • фрагменты схем БД и т.д. Для каждого типа модулей есть стандартные утилиты, может использовать их? 2 / 22
  • 3. Стандартные утилиты Composer, Bower, Volo, Jam и т.д. • ориентация на централизованные внешние реестры и github (большинство) • сложность настройки частных репозиториев («вам понадобится CouchDB...» what??) • невозможность использования ссылок на разрабатываемые модули (например, нет аналога npm links в composer) • установка полной копии, избыточной для runtime (bower) • слишком много конфигурации 3 / 22
  • 4. Наши потребности • установка необходимого runtime-кода в проект • версионность, учет зависимостей • единое решение для серверных и клиентских модулей • адаптация под используемый нами инструментарий • возможность установки в проект произвольной структуры • гарантированная совместимость компонент между собой • минимум конфигурации 4 / 22
  • 5. Что нам не важно • взаимодействие со сторонними разработчиками (внутренняя платформа) • интеграция с github • установка по сети — некритично, достаточно локальной доступности на сервере разработки • избыточная конфигурируемость — лучше convention over configuration • buzzword compatibility — нам ехать, а не шашечки 5 / 22
  • 6. gears • стандартный git-репозиторий используемых модулей • каждый модуль содержит только код, необходимый в runtime или для сборки runtime • файлы модуля — подмножество файлов соответствующего проекта, разработка модуля — в отдельном репозитории • каждый модуль имеет версию, репозиторий определяет зависимости между версиями • утилита командной строки для установки модулей с зависимостями • использование симлинков при установке модулей в проект 6 / 22
  • 7. Структура модуля Метаданные: package - краткое описание модуля manifest - перечень устанавливаемых в проект файлов LICENSE - текст лицензии модуля README.md - описание модуля Каталоги с устанавливаемыми файлами: js/ - модули JavaScript css/ - css, less или styl img/ - стандартные изображения tpl/ - PHP-шаблоны lib/ - PHP-классы fnt/ - шрифты 7 / 22
  • 8. Версионность модулей Каждому модулю соответствует символическое имя: 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. Версионность платформы • версия платформы определяется индекс-файлом, описывающим зависимости • внутри одной версии платформы модули гарантированно совместимы • появление новой версии платформы не отменяет существование предыдущих • версия платформы может быть удалена, если не осталось проектов, использующих эту версию • переход проекта на новую версию может потребовать внесение изменений в проект 9 / 22
  • 10. Структура репозитория .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. Требования к установке Модули могут быть установлены в произвольный проект, поэтому: • структура модуля не должна зависеть от структуры проекта • смена версии модуля не должна влиять на его подключение в проекте • модули могут быть легко переустановлены или установлены с нуля • файлы модулей можно легко исключить из контроля версий проекта, если это необходимо • пути не должны зависеть от версий модулей 11 / 22
  • 12. Установка в проект • все модули устанавливаются в специальный выделенный каталог ext • на файлы модулей создаются симлинки в других каталогах проекта • имя подкаталога модуля соответствует его полному имени с номером версии • симлинки в подкаталогах проекта — через промежуточный симлинк, соответствующий чистому имени модуля без версии 12 / 22
  • 13. Структура файлов проекта 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
  • 14. Установка в проект • используемые версии компонентов легко контролировать • промежуточный симлинк позволяет менять версию модуля без изменения симлинков в проекте • для одновременной разработки модуля вместе с проектом можно использовать временный симлинк на разрабатываемую версию • можно использовать PHP autoloader прямо из ext А не слишком много симлинков? • практически не влияют на производительность • симлинки в src не используются в runtime 14 / 22
  • 15. Клиентские модули Почему просто не использовать bower? Избыточность файлов и отсутствие адаптации под наши условия. Адаптация: • преобразование в формат AMD • исправление ошибок и реализация недостающего функционала • преобразование CSS в Stylus для параметризации и включения в общую цепочку генерации CSS • всегда включаем полную версию, минимизация выполняется в проекте при сборке • включаем только то, что необходимо в runtime 15 / 22
  • 16. Серверные модули Почему просто не использовать composer? Слишком много телодвижений и сложность одновременной разработки модуля и проекта. • PHP-классы + файлы шаблонов • используем стандартные autoload.php, не нужно дополнительно конфигурировать автозагрузчик • не используем composer для установки в проект, что не отменяет возможность его использования внутри модуля • каталог шаблонов включается в общую иерархию шаблонов проекта 16 / 22
  • 17. Серверные, клиентские ... Просто модули • модуль может включать в себя файлы как для серверной, так и для клиентской части • модуль — просто набор файлов, устанавливаемых по стандартным правилам 17 / 22
  • 18. Автоматизация установки # Установка из версии платформы 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
  • 19. Использование репозитория • должен ли проект строиться только из модулей репозитория — нет • накладывает ли использование репозитория ограничения на структуру проекта — нет • можно ли использовать непосредственно ссылки на модули репозитория — нет, за исключением случаев отладки • должен ли ext включаться в git-репозиторий проекта — зависит от ситуации, можно не включать, если необходимые модули могут быть установлены автоматически 19 / 22
  • 20. Поддержка репозитория • необходимо периодически отслеживать новые версии модулей сторонних разработчиков — да • необходимо проверять совместимость новых версий в рамках платформы — да • кто поддерживает репозиторий — менеджер репозитория (один-два выделенных разработчика) • когда — по необходимости + периодически (например, каждый месяц) • новые модули — по запросу разработчиков проектов и библиотек 20 / 22
  • 21. Что выигрываем • переходим от разрозненных библиотек к единой корпоративной платформе • минимизируем зоопарк версий в проектах • стараемся использовать компоненты не из репозитория только если это действительно необходимо • решаемые задачи относительно типовые — со временем репозиторий перестает расти и содержит набор проверенных типовых компонент • максимально простая организация — не зависит от особенностей развития внешних инструментов 21 / 22
  • 22. gears private: https://bitbucket.org/interlabs/gears 22 / 22