Докладний блог нашого Drupal-розробника про
використання Drupal Composer шаблона і Phing.
Він написаний з точки зору останньої версії Drupal — Drupal 8.
Кожен розробник день у день стикається з рутинними задачами незалежно від напрямку розробки, будь то front-end, back-end чи QA. Більшість з нас звикли максимально оптимізувати будь-який робочий процес, в чому нам допомагає велика кількість наявних технологій. І навіть такі прості задачі, як свіже встановлення Drupal або оновлення локальної бази з базою дев-сервера, можуть стати стимулом для створення ряду інструментів, які дозволять оптимізувати подібні завдання.
У зв'язку з цим хотілося б розглянути два простих інструменти, які і вирішують перелічені вище задачі (і не тільки їх). У зв'язку з тим, що в даний момент для нас найбільший інтерес представляє Drupal 8, то і інструменти будуть розглянуті виходячи з роботи з цією версією, хоча обидва можуть працювати і з Drupal 7 (для Phing версія Drupal в принципі не важлива).
Drupal Composer шаблон для Drupal проектів
Як можна зрозуміти з назви, мова піде про інструмент, створений на основі принципів роботи з Composer для оптимізації і прискорення встановлення і подальшого оновлення Drupal-проектів (будь то оновлення ядра або встановлення/оновлення контриб-модулів).
Інструмент доступний на github за посиланням і основна частина роботи з ним полягає в одній команді:
composer create-project drupal-composer/drupal-project:8.x-dev some-dir --stability dev --no-interaction
де some-dir — це назва папки, яка буде створена для проекту, а 8.x — гілка і, відповідно, версія Drupal для встановлення.
Варто звернути увагу, що для роботи з цим інструментом повинен бути встановлений Composer, а якщо він встановлений, то може знадобитися його оновлення до версії зі stable каналу 1.0.0 і вище (про що ви будете попереджені в вашому терміналі).
Запустивши створення проекту, можна піти почитати задачу в вашому bug/issue трекері, тому що це забере деякий час.
Коли все залежності будуть завантажені і проект створений, можна звернутися в папку з браузера і продовжити стандартний процес встановлення Drupal.
Розглянемо основні плюси використання цього інструменту.
Структура файлів:
Як видно на зображенні, сам Drupal, а саме його ядро, модулі, теми і профілі лежать в папці рівнем нижчій за корінь (папка web), що робить файли в корені недоступними ззовні. Варто звернути увагу, що ваш віртуальний хост (apache) або сервер блок (nginx) повинен дивитися саме в папку web. Все контриб-модулі, теми і профілі за замовчуванням будуть встановлюватися в папку contrib всередині відповідної папки (web/modules, web/themes, web/profiles), що відокремить їх від кастомного коду. Варто звернути увагу, що якщо ви для чогось розмістите кастомний код в contrib папці (не варто цього робити), то він не потраплятиме під версійний контроль (читати далі).
Версійний контроль. Як видно з файлу .gitignore в корені проекту, під версійний контроль не потраплятимуть такі папки, як vendor, core, contrib, files. Таким чином, в репозиторії будуть тільки необхідні файли для Composer, кастомний код, додаткові файли налаштувань в залежності від ваших вимог до проекту.
Додаткові компоненти за замовчуванням. Після встановлення розробнику доступні два дуже важливих інструменти — Drush і Drupal console, що означає, що їх не обов'язково встановлювати в системі завчасно. Запустити їх можна з папки web, використовуючи наступні команди:
../vendor/bin/drush some-command ../vendor/bin/drupal some-command
Pre/post install/update скрипти/команди/методи. В папці scripts/composer лежить php файл з класом ScriptHandler і стандартними методами. Якщо проект вимагає додаткових перевірок/створення файлів і т.п., то є можливість додати свій метод в даний клас і додати виклик даного методу в секції scripts composer.json файлу. У даній секції є приклади виклику методів для запуску під час pre/post install/update подій. Також в секцію scripts можна додати виклик своєї команди або запуск shell скриптів, що допоможе зробити деякі процеси ще більш автоматизованими.
Основні плюси використання даного інструменту розглянуті, і важко не погодитися, що цей підхід непогано оптимізує час на розгортання чистого проекту і подальшу його підтримку, тому що самостійна реалізація описаних плюсів забрала б значно більше часу.
Що ж стосується подальшого використання, то воно полягає в тому, що встановлення модулів, оновлення ядра, застосування патчів тепер лягає на плечі Composer. Для прикладу, встановлення контриб-модуля layout plugin виглядає так:
composer require drupal/layout_plugin:8.1.0-alpha22
A оновлення ядра Drupal:
composer update drupal/core
Зверніть увагу, що встановлення модулів буде відбуватися з репозиторія пакетів, зазначеного в composer.json файлі, але він deprecated і пізніше буде замінений на офіційний репозиторій пакетів від drupal.org ), а також на те, що вказання версії модуля трохи відрізняється від версії, зазначеної на drupal.org (версію модуля layout plugin з drupal.org виду 8.x-1.0-alpha22 Composer не прийме, тому що він використовує більш правильне версіонування виду 8.1.0-alpha22).
PHING для Drupal-проектів
Прийшов час поговорити про задачі, з якими ми стикаємося набагато частіше, ніж завантаження і встановлення свіжого Drupal-проекту.
Припустимо, що у нас є готова збірка Drupal 8, яка за основу використовує Drupal Composer шаблон, описаний вище, і зараз ведеться активна розробка проекту. Як виглядає процес оновлення локального інстансу сайту до стану зі сховищ (версійний контроль), де лежить проект? Це робиться набором певних команд:
git pull origin master // візьмемо найпростіший варіант без придумування додаткових репозиторіїв і гілок composer install // можливо, хтось додав новий модуль, і вам потрібно його встановити drush config-import // з пулом прийшли нові конфіги, і їх потрібно імпортувати в вашу базу drush updb // запустимо апдейти бази drush entup // оновлення сутностей drush cr // keep calm and clear cache :)
Описано найпростіший випадок, зустрічатися з яким доведеться по кілька разів на день під час активної розробки, але і цей випадок містить набір з 6 команд, написання яких може добряче набриднути, а вам, можливо, потрібно запустити bower, міграції, unit тестування, або будь-який інший інструмент, який використовується на проекті.
На допомогу приходить PHING — інструмент для збірки на основі Apache Ant.
Оскільки вже ми використовуємо Drupal Composer шаблон і вважаємо, що Phing на проекті будуть використовувати всі, то і встановимо його, використовуючи Composer спеціально під наш проект (вибір локального або глобального встановлення за вами, цей випадок просто для прикладу):
composer require-dev phing/phing:2.* //
(під час прочитання статті версія може відрізнятися).
Після цього в папці vendor вашого проекту з'явиться папка phing. Все, що нам потрібно, щоб спростити наше і без того непросте життя, це xml білд файл з 3-ма складовими:
- 1. Задача (Task) — код, який викликає специфічну функцію (git pull, mkdir, etc.)
- 2. Мета (Target) — список завдань, який може бути залежним від іншої мети
- 3. Проект (Project) — рут елемент, який складається з цілей
Виходячи з наявних даних напишемо наш перший простий білд файл, щоб оптимізувати ті самі 6 команд, описані вище.
Створюємо файл build.xml в корені проекту, залишаємо його під версійним контролем, щоб інші розробники теж могли його використовувати (якщо вже Phing встановлений локально під проект). Бажано не забути про те, що файл не повинен піти далі dev/stage середовища, адже це зайве.
Опишемо Project файлу:
<?xml version="1.0" encoding="UTF-8"?>
<project name="Awesome project" default="build" basedir="." description="Build site"> // here are targets will be (Target). </project>
У project елемента є кілька атрибутів, призначення яких ясно з назви, але звернути увагу хотілося б на атрибут default — це ім'я мети (Target), яке буде використовуватися за замовчуванням, якщо при запуску Phing команди не вказано ім'я мети. Опишемо мета і завдання для нашого випадку:
<target name="build">
<exec command="git pull" dir="." description="Fetch data from cvs repository." logoutput="true"/>
<exec command="composer install --no-interaction" dir="." description="Install missing composer packages." logoutput="true"/>
<exec command="../vendor/bin/drush -y config-import" dir="web" description="Import drupal configuration." logoutput="true"/>
<exec command="../vendor/bin/drush -y updb" dir="web" description="Run drupal update database hooks." logoutput="true"/>
<exec command="../vendor/bin/drush -y entup" dir="web" description="Run drupal entity update hooks." logoutput="true"/>
<exec command="../vendor/bin/drush -y cr" dir="web" description="Rebuild the cache." logoutput="true"/>
</target>Як бачимо, синтаксис мети і завдань досить простий. Варто звернути увагу, що створена мета має ім'я, яке зазначено в default атрибуті рут елемента, що означає, що даний список команд і буде виконуватися за замовчуванням.
Ось загалом і всі основи роботи з Phing. Остаточний вигляд білд файлу буде таким:
<?xml version="1.0" encoding="UTF-8"?> <project name="Awesome project" default="build" basedir="." description="Build site">
<target name="build"> <exec command="git pull" dir="." description="Fetch data from cvs repository." logoutput="true"/> <exec command="composer install --no-interaction" dir="." description="Install missing composer packages." logoutput="true"/> <exec command="../vendor/bin/drush -y config-import" dir="web" description="Import drupal configuration." logoutput="true"/> <exec command="../vendor/bin/drush -y updb" dir="web" description="Run drupal update database hooks." logoutput="true"/> <exec command="../vendor/bin/drush -y entup" dir="web" description="Run drupal entity update hooks." logoutput="true"/> <exec command="../vendor/bin/drush -y cr" dir="web" description="Rebuild the cache." logoutput="true"/> </target> </project>
а запуск виконання команд:
phing // із кореня проекту, де лежить сам білд
Звісно, це далеко не всі можливості даного інструменту. Він має власну документацію, яка допоможе будувати набагато складніші білд файли.
В якості бонусу хотілося б поділитися ще однією метою (target), яка буде корисна для отримання бази з дев/стейдж сервера всього однією командою:
<target name="sync">
<exec command="../vendor/bin/drush -y sql-drop" dir="web" description="Drop the database." logoutput="true"/>
<exec command="../vendor/bin/drush -y sql-sync @stage @self" dir="web" description="Sync database from stage." logoutput="true"/>
<exec command="../vendor/bin/drush -y cr" dir="web" description="Rebuild the cache." logoutput="true"/>
<exec command="../vendor/bin/drush -y cim" dir="web" description="Import drupal configuration." logoutput="true"/>
<exec command="../vendor/bin/drush -y updb" dir="web" description="Run drupal update database hooks." logoutput="true"/>
<exec command="../vendor/bin/drush -y entup" dir="web" description="Run drupal entity update hooks." logoutput="true"/>
</target>Помістивши даний target в project вашого білд файлу, ви зможете з легкістю синхронізуватися з дев/стейдж однією командою:
phing sync // sync
— ім’я створеного target.
Також запуск phing білдів можна об'єднати з Composer pre/post install/update хуками, описаними в розділі Drupal Composer.
Сподіваюся, дана інформація була корисна і скоротить витрати часу на деякі задачі.