Ласкаво просимо в країну F нкціі C onfiguration M ПРАВЛІННЯ, інакше ТСМ ! Йдеться не лише про функції , а не про управління конфігурацією (як це було введено у версії 8 Drupal). Замість цього, він є окремим випадком S oftware C onfiguration M ПРАВЛІННЯ , інакше SCM . Переважно тому, що Особливості можна розглядати як генератор коду, тоді як створений код потрібно мігрувати через декілька середовищ. Детальніше читайте далі.
1 - плюси і мінуси використання функцій
Переваги використання функцій
- Автоматизувати розгортання змін, застосованих до сайту розробки Drupal, до одного або декількох цільових виробничих сайтів Drupal (перед) (замість ручного розгортання).
- Сприяє обміну (доставці) поточної розробки Drupal між розробниками / розробниками сайтів Drupal (наприклад, для того, щоб зробити деякі перегляди, створені експертом з видань, доступним для Drupal Themer, який працює на іншому веб-сайті для розробки, щоб обговорити цю проблему).
- Відмінна інтеграція як з GIT, так і з Drush для доставки копії коду, згенерованого функціями (на сайті розробки), до вибраних цільових (до) виробничих сайтів.
Недоліки використання функцій
- Уникнення конфліктів функцій та / або управління залежностями функцій може бути складним завданням!
- Почати використання функцій на неістотному (виробничому) сайті непросто .
- Встановити / увімкнути модуль " Особливості" просто (лише модуль), але навчитися правильно використовувати функції - головна проблема.
2 - Методи упаковки функцій
Використання функцій залежить від вашої власної фантазії, як упакувати (скласти) вміст функції. Ось кілька прийомів, які можна використовувати для цього.
Єдина суперфункція
Це досить проста техніка упаковки: все упаковується в єдину функцію (деякі називають це "богом" функцією ...). Здається легко, досить вперед і т. Д. Але ця методика також призводить до «конфліктів» (як пояснено нижче) більш-менш відразу ...
Хороший корисний приклад для цього виглядає при створенні "Drupal-дистрибутива", де всі його користувачі повинні використовувати один і той же набір модулів, конфігурацію і т.д. "особливості" ...), видається більш доцільним розділити такі функції на кілька функцій, як пояснено нижче.
На основі функціональності веб-сайту
Ця техніка упаковки створює окрему функцію для кожної функції веб-сайту, наприклад:
- Особливість A = реалізуйте " * Галерею ".
- Особливість B = реалізувати блог " * ".
- Особливість C = реалізувати " * Календар подій ".
На основі розділів Drupal Administrator
Ця техніка упаковки створює окремі функції для кожного (головного) розділу адміністратора веб-сайту Drupal, який використовується для створення сайту, наприклад:
- Усі необхідні модулі містяться у функції A,
- Усі визначення базового поля містяться у функції B,
- Усі типи вмісту містяться у функції C,
- Усі дозволи містяться у функції D,
- Усі ролі містяться у функції E,
- Усі змінні містяться у функції F,
- Усі (власні) перегляди містяться у функції G,
- Усі (спеціальні) правила містяться у функції H,
- І т.д.
Наведений вище список практично необмежений: врешті-решт, ви навіть можете подумати про це як про 1 функцію для кожного меню адміністратора Drupal ... якщо ви хочете піти так далеко.
IMO - це також найбільш рекомендований підхід до функцій пакету.
3 - Зменшення ймовірності конфліктів у Особливості та / або GIT
Не використовуйте повторно поля
Здається, що декілька конфліктів викликані повторним використанням полів серед кількох типів вмісту. Наприклад, у типі вмісту A у вас є поле з назвою машини field_somefield, яке також використовується як поле у вмісті типу B з тим самим іменем машини, field_somefieldале яке є іншим типом поля та / або іншими налаштуваннями поля, які відрізняються.
Не використовуючи поля серед типів вмісту, ви уникаєте запуску в цьому випуску. Погляньте на цікаву конвенцію щодо іменування машинних назв типів вмісту та полів, як показано в таблиці Архівної архітектури та документації для обтікання інформацією , яка є частиною статей про " Модель відносності для Drupal ". Більш детальну інформацію про це див. У моїй відповіді на тему " Як я моделюю вміст (типи) з точки зору, орієнтованого на базу даних? ".
Розділити функції залежно від того, хто над чим працює
Якщо на одному сайті працює декілька людей, кількість конфліктів можна зменшити, організувавши (= створивши окремі) функції залежно від того, хто над чим працює. Ілюстрація цього може бути, як у цьому прикладі:
4 - Рекомендоване середовище Drupal
Усе вище, що допоможе, допоможе якось полегшити використання функцій . Однак, щоб забезпечити, що все буде працювати так, як очікувалося (розроблено), вам також необхідно мати відповідний набір середовищ (логічно пов’язані веб-сайти Drupal) з цих причин:
- функціональність злиття, що надається кількома функціями.
- прогнозувати та вирішувати конфлікти.
- тестування кінцевим користувачем усіх об'єднаних функцій, сертифікованих на відсутність конфліктів.
В ідеальному світі ці логічно пов’язані веб-сайти Drupal повинні бути налаштовані та використані так:
- Персональний веб-сайт розробників - кожен розробник веб-сайту має окремий розробник. Коли якась частина розробки готова поділитися з кимось іншим, створюється відповідна функція, яка надсилається до сценічного середовища.
- Сайт пісочниці - це середовище Drupal, яке містить лише ядро Drupal, яке використовується для перевірки повноти однієї функції. Якщо випадково функція має деякі несподівані залежності (наприклад, якийсь модуль залежить від функції, який не ввімкнено в пісочниці), саме тут ця залежність стане зрозумілою.
- Постановочний сайт - тут передається одна або кілька функцій (створених на сайті розробників). Це може бути лише якесь виправлення для певної виробничої проблеми, або це може бути консолідована вся розробка нового випуску веб-сайту. Якщо існують будь-які конфлікти між різними можливостями, то це середовище, де вони вперше з’являться ... і їх потрібно якось вирішити.
- Сайт QA - після того, як середовище Staging вважається стабільним, настав час перейти до відповідних функцій та зробити їх доступними також на якомусь більш високому рівні, де їх можна використовувати для тестування якості, приймання тестування, тестування обсягу тощо. На цьому рівні ви слід бути надзвичайно обережним у допущенні будь-яких додаткових змін (якщо такі є). Оскільки будь-яка така зміна може призвести до недійсності всіх попередніх випробувань, вже виконаних у цьому середовищі.
- Shadow Production Site - Щоб підготувати активацію в реальному виробництві, вам варто спочатку додатково просувати відповідні функції до середовища, яке вважається копією (тінню) вашого реального виробничого середовища. Якщо в цей момент під час міграційного процесу все-таки щось зламається, то це червоний прапор для повернення деяких попередніх кроків. Виправте це та повторіть спробу, поки всі зацікавлені сторони не затвердять зміни.
- Виробничий сайт (и) - Якщо ви виконали всі попередні кроки, то цей крок повинен бути самостійним поясненням і досить легким. Залежно від ваших потреб, це може бути один веб-сайт або щось еквівалентне Multi-сайтам Drupal, тоді як усі задіяні сайти мають ті самі версії всіх функцій.
- Базовий сайт - на мій досвід, існує не так багато (якщо вони взагалі є) реалізацій Drupal, де використовується такий тип сайту (також). Це просто копія Виробничого сайту, але доступна розробникам, тестерам Drupal та ін., Які можна перевірити, як виглядають виробничі майданчики, або провести навчання користувачів тощо. І будь-який час нова розробка цикл запускається, компоненти сайту, на які впливатимуть (потрібно змінити), слід «якось скопіювати», використовуючи цей базовий сайт як вхідний файл, з цільовим сайтом особистого розвитку .
Очевидно, що вищеописаний опис типів сайтів Drupal - це як ідеальний світ. Залежно від розміру вашої команди розробників та / або наявних бюджетів для їх створення та обслуговування, не всі вони можуть використовуватися (або доступними). Цей інвентар складається за зразком найкращих практик у галузі СКМ, використовуваних в основному у всіх величезних / глобальних корпораціях (банках, авіакомпаніях тощо).
5 - Суміжні модулі
Сильна зброя
Модуль Strongarm дозволяє експортувати змінні (модулів, які зберігають їх налаштування у змінних) за допомогою модуля "Особливості".
Експорт вузлів
Модуль експорту вузла дозволяє користувачам експортувати вузли, а потім імпортувати їх в іншу установку Drupal.
Експорт ролей
Модуль експорту ролей дозволяє ролям мати імена машин та генерувати унікальний ідентифікатор ролей (позбавлення), виходячи з імені машини. Ролі можна експортувати за допомогою функції та точно позбутися, якщо їх імпортувати на інших сайтах.
Особливості Banish
Модуль функцій Banish дозволяє повністю виключити компоненти окремих функцій з інтерфейсу функцій та експорту функцій. Ось цитата про це зі сторінки проекту:
Цей модуль корисний, коли є компоненти функцій, які ви хочете переконатися, що НІКОЛИ не експортуйте. Якщо ви використовуєте функції для створення або розгортання сайтів, ви, мабуть, зіткнулися з проблемою, коли хтось випадково експортує змінні часові позначки, наприклад cron_last або update_last_check. Ви також можете скасувати дозволи для модулів розробника, щоб вони не потрапляли до решти дозволів на сайт, які ви хочете експортувати. Заборонені елементи не відображатимуться у вашому модулі функцій АБО БУДЬ-ЯКІЙ ІНШИЙ МОДУЛЬ ДІЯЛЬНОСТІ, тому користуйтеся обережно. Про центральний список функцій, які ніколи не слід експортувати, див. Https://www.drupal.org/node/2400531
БИЛО
Модуль Bean робить ваші блоки експортом. Ось цитата про це зі сторінки проекту:
Подумайте про Бін як про спосіб надання нових типів (порівняно з вузлом, це буде тип вмісту), який надає інтерфейс для додавання вмісту для створення стільки блоків, скільки вам потрібно (див. Знімок екрана нижче). Вміст бобів може бути розміщений навколо сайту, як і будь-який інший блок.
Цей модуль також чудово працює в поєднанні з модулями інтеграції функцій UUID та UUID . Цей модуль розпочався лише з D7, але він уже включений до ядра Drupal 8. Навчальний посібник з модулем Drupal Bean для відео - використання інтерфейсу Bean Admin дає чудове введення, щоб дійсно зрозуміти потужність цього модуля та види того, що ви можете зробити з ним (використовуючи лише методи побудови веб-сайтів, не включаючи спеціальне кодування).
Хабітат
Модуль Habitat має найбільш сенс у робочому процесі, що базується на особливостях . Ось цитата про це зі сторінки проекту:
У налаштуваннях для багатьох середовищ (наприклад, prod, test, dev, local) є деякі модулі, які ви хотіли б завжди бути увімкненими або відключеними в певних середовищах. Кожен раз, коли ви синхронізуєте базу даних, хоча вам доведеться знову вмикати / відключати одні й ті ж модулі. Гірше, що ви лінуєтесь і утримуєте модулі розробки на виробництві.
Хабітат забезпечує налаштування для включення або відключення певних модулів у кожному середовищі (середовищі існування). Просто встановіть змінну, наприклад, $ conf ['habitat'] = 'local'; у вашому файлі settings.php (фактична змінна, яку слід використовувати, може налаштовуватися під поточний робочий процес). Модулі відключення / включення здійснюються на гачку_init.
6 - Рекомендовані ресурси:
7 - Можливі варіанти використання функцій
Якщо ви не в змозі або не хочете (ще) користуєтеся функціями , можливо, вам захочеться перевірити, наскільки розширені підходи / модулі нижче можуть запропонувати певний тип альтернативи.
Експорт / імпорт вручну
Це загальновідомі засоби (щоб уникнути функцій слова ...), доступні через інтерфейс адміністратора, для модулів, таких як Правила , Перегляди тощо (неповний список!).
Копія в комплекті
Деякі люди розглядають модуль копіювання пакета як можливу альтернативу. Він має підтримку експорту / імпорту для:
- Типи вузлів.
- Таксономія.
- Користувач.
- Поля API поля.
- Польові групи.