Який запропонований робочий процес для міграції (CMI) конфігурації з dev -> stage -> production?

41

Кілька місяців тому у нас був drupalcamp, і хтось запитав про управління розгортаннями з новою системою config (CMI). Один з можливих ідеальних робочих процесів передбачав би збереження конфігурації в контролі версій та можливість перенесення конфігурації між членами команди.

Найкраще, що ми змогли розібратися в кімнаті (частково на основі презентації в DrupalCon Portland):

Скажіть керування версіями ігнорувати активний каталог конфігурацій.
Скопіюйте всю Конфігурацію в каталог інсценізацій та перекладіть на контроль версій.

І використовуйте settings.php, щоб повернути активний / послідовний каталог між двома середовищами. Однак, хоча з'ясування робочого процесу розгортання з одного сервера на інший було складним, але здійсненним, який запропонований робочий процес із кількох локальних середовищ (тобто декількох розробників) перетворюється на розробник (або між собою) - можливим питанням буде кожен член команди ділиться тим самим чи подібним середовищем, тож як змінюються зміни на машині одного товариша по команді?

migration 8 version-control

— btmash
джерело

5

Я дійсно не згоден з поточними голосувальниками. Оскільки CMI є фокусом для Drupal 8, я думаю, що тут ми можемо отримати кілька хороших відповідей.

— mpdonadio

3

Згоден, це дуже гарне питання. Я вважаю, що важливе завдання drupal.org/node/1703168 стосується цієї та інших тем і ще не вирішена повністю, тому відповіді тут можуть допомогти просунути це питання вперед.

— Бердір

Прошу вибачення, якщо моє запитання було негативним щодо ініціативи CMI (що зовсім не було моїм наміром). Я оновив питання, щоб воно звучало більш нейтрально.

— btmash

2

я майже збирався сказати "Ви спробували функції". Можливо, "D8" має входити в назву питання? Тег "8" трохи непомітний.

— donquixote

1

Переглянуто заголовок, щоб питання можна було побачити як тегом, так і через заголовок :)

— btmash

19

Після невеликої розмови з сервісниками CMI, дискусія про те, який найкращий підхід не закінчена, але наступне - що має найбільш сенс на даний момент.

Намагаючись зберегти це на сьогоднішній день, він спробує розширитись на основі запитань / коли питання, на яке посилається, вирішено офіційною відповіддю.

Отже, по-перше, факти ...

Як уже згадувалося, існує активний та інсценіруючий каталог. Active повністю управляється Drupal, внесення змін безпосередньо там (прямі або непрямі шляхом переходу в інше місце) не підтримується.
Постановка - це те, коли Drupal шукає конфігурацію для імпорту, а інакше не піклується про це.
Процес імпорту є важливим, зміни конфігурації можуть певним чином впливати на сайт і його потрібно перевірити на наявність дійсності. Ви не можете змінити тип поля текстового поля на посилання на об'єкт, наприклад, це просто не працює.
Імпорт конфігурації завжди повинен працювати в усіх конфігураціях, ви не можете імпортувати один вид або тип вузла. Це намагалося, але намагання впоратися із залежностями, видаляє / перейменовує і так далі призвело до дуже складної системи, і вона не спрацювала.
Єдиний спосіб перевстановити конфігурацію за замовчуванням - це повторна установка цього модуля. Що означає, що спочатку спробує видалити всю конфігурацію (наприклад, поля). Тож це насправді не варіант. Вручну, конкретні зміни функцій оновлення можливі, але занадто виснажливі для цього.
Як описано в модулі функцій, він буде зосереджений на наданні функціональних можливостей, що використовуються повторно, а не постійних розгортаннях конфігурації. Саме для цього він був розроблений в першу чергу.

Враховуючи це, зараз рекомендуємо ввести каталог інсценізації в контроль версій. Кожен розробник має повний контроль над тим, що він розміщує, або копіюючи весь активний каталог, або просто певний файл конфігурації. Після цього здійснюються зміни каталогів інсценізації, висуваються на виробництво і виконується імпорт конфігурації (в інтерфейсі користувача або за допомогою друку).

— Бердір
джерело

Каталог постановок у контролі версій, я отримую цю частину. Інші частини - це те, що мій розум намагається обробити. Тож якщо хтось вносить зміни, він копіює свої зміни до каталогу інсценізацій і робить це. Після цього інші розробники / наступний сервер отримують зміни та синхронізують зміни до активного каталогу. І промийте та повторіть будь-який інший ланцюг сервера по дорозі (постановка, виготовлення тощо). І це завжди проходить поетапно, тому більше не відбувається переключення каталогу. Це було б точно?

— btmash

Так. Не повинно бути комутації каталогів. Кожна зміна конфігурації має пройти через процес імпорту, інакше ви можете зірвати сайт. Наприклад, список модулів також є конфігурацією. Розгортання означає, що модулі потрібно встановити / видалити (Примітка. Це ще не працює, але є проблема, щоб виправити це).

— Бердір

Гаразд, тож ще більше запитань (розділіть на 2 коментарі) :) По-перше, ви згадаєте модулі конфігурації. Тож навіть якщо модуль додано до репо і не ввімкнено / вимкнено, його потрібно встановити / видалити, щоб просто сидіти там?

— btmash

А далі: (A) Чи буде механізм копіювання змін з активного каталогу -> staging (щоб спростити порівняно з людиною, що потрапляє в каталог конфігурацій для цих компонентів - можливо спосіб вибору певних змінних). (B) Чи видаляється каталог інсценізації після синхронізації змін із стадією -> активною? (B1) Якщо так, то чи є стратегія з точки зору devops для скидання цього каталогу до виведення git? (В2) Якщо ні, то чи правильно вважати, що під час постановки> активна синхронізація не повинна впливати на конфігурацію, яка не змінилася?

— btmash

Статус установки модуля - це конфігурація. Не сам модуль :) Це те, що ви розгортаєте. a) Існує інтерфейс для завантаження tar.gz активного каталогу, один для завантаження вказаного tar.gz в каталог постановок, а також власне імпорт з оглядом та різницею змін. Б) Я вірю, що зараз вона спорожнена, але я припускаю, що ви можете легко повернути це за допомогою git. Не впевнений, легко перевірити. Весь цей матеріал підключається, тому може бути дещо інша реалізація, яка не видаляється. B2) Я не розумію цього, але думаю, що так.

— Бердір

4

Чудова відповідь поки що. Дякую всім вам!

Нещодавно ми розпочали проект Drupal 8 і реалізували наступний робочий процес.

У нас є три активні папки, постановка та експорт. Розробники скидають їх на експорт. Я не хочу тримати це у постановці. Я думаю, що з ним простіше працювати, коли спільна конфігурація безпосередньо не зберігається в папці інсценізації. Це просто рублі, у мене немає важких фактів з цього приводу ...

Наш поточний шаблон проекту drupal 8 доступний на github. Я також написав кілька зручних команд ударних для прискорення робочого потоку розробника. Ручне копіювання з активного експорту не потрібно.

Шаблон проекту: https://github.com/webflo/d8-project-template
Додаткові команди Drush: https://github.com/webflo/d8-project-template/blob/master/public/drush/cmi.drush.inc

— webflo
джерело

1

Поки я згоден з таким підходом. Я додав усі функції з посилань у цій публікації до команд Drush config-export та config-import. Я сподіваюся, що інші приєднаються до мене та @florian при вивченні цього 3-го каталогу рішення.

— moshe weitzman

Як поводитися з sites/default/files/config_HASHпапкою config, що має хеш-суфікс, наприклад config_wNOLcmycPFZCrXJ9wis9dCdSR4lpYILdBsFxSWuK5Hzhcr

— therobyouknow

@therobyouknow Можна змінити розташування цих папок. Просто шукайте "Розташування файлів конфігурації сайту". у settings.php я використовую такий фрагмент. Це означає, що конфігурація зберігається поза кореневим режимом Drupals. $ config_directories = array ('active' => '../config/active', 'staging' => '../config/staging',);

— webflo

Дякую @webflo Я це бачив. Яка була б користь від керування базою коду та конфігурацією окремо? Я думаю, що це розділення трохи штучне, оскільки і код, і конфігурація (в ямлі) визначають поведінку і залежать один від одного. У Drupal 7 конфігурацію коду (або відслідковується за допомогою Git) було виконано за допомогою модуля "Особливості", що створює модуль для кожної конкретної конфігурації, яку потрібно було відслідковувати в коді. У Drupal 8 є Особливості 3.x, яка, як я розумію, робить те саме, але використовує YAML для зберігання конфігурації, а згенеровані модулі не залежать від модуля "Особливості".

— therobyouknow

Думаю, ти мене зрозумів неправильно, конфігурація режисура все ще знаходиться в git, але мій сайт Drupal не в корені git repo. Сайт зберігається / веб. Отже / config та / web знаходяться на одному рівні.

— webflo

2

Я ще цього не пробував, але мій план полягає у створенні спеціального модуля, який містить "конфігураційні" файли "за замовчуванням", що містять лише конфігурацію, яка мені цікава. Я вважаю, що інші модулі можуть містити конфігури, які перекривають інші модулі. (Якщо ні, це має бути зроблено можливим).

Я думаю, ви повинні залишити конфігураційну папку в спокої. Ігноруйте це. Він автоматично генерується при встановленні з усіх конфігураційних файлів окремих модулів. Шлях довгий і випадковий. Якщо ви все це зберігали в репо, вам знадобиться окреме репо, і ви б несли разом з ним тонни непотрібних конфігураційних файлів за замовчуванням.

Якщо ввести конфігурацію у спеціальний модуль, це стане частиною основної бази даних коду.

Процес розгортання буде:

Git pull або що завгодно, щоб отримати нові файли
Очистити кеші.
Скинути конфігурацію за замовчуванням. (З файлів власного модуля)

Ви можете створити спеціальні модулі (з власною конфігурацією) для кожного середовища, якщо хочете.

— jonpugh
джерело

Це дуже схоже на функції, чи не так? Або є суттєва різниця, якої мені не вистачає?

— Летаріон

Це цікавий підхід, і мені подобається ідея. Однак однією з найбільших переваг, про яку було сказано в рамках ініціативи CMI, є можливість переміщення по конфігурації з конфігураційних каталогів. І з того, що я бачу, файл settings.php дозволяє вам диктувати, де перебувають активні / інсценірующіе каталоги (тобто, їм не потрібно автоматично генерувати контури). Отже, я думаю, що робочий процес із поточною конфігурацією повинен бути можливим без необхідності створювати функцію, як згадує @Letharion вище.

— btmash

2

Примітка. Я вдячний, що це не відповідь у найсуворішому сенсі стосовно питання, але я все-таки поставив його тут і я перегляну та редагую / видалюю, коли в розділі "Особливості" буде випуск 8.x і пил влаштувались трохи більше. Це було занадто великим для коментаря, і я хотів отримати 0,02 фунта за :-)

Як великий шанувальник функцій , я б запропонував стежити за втіленням D8 модуля Особливості .

Зібрано зі сторінки проекту

3.x версія Особливості планується для Drupal 8 інтегрувати з новою системою управління конфігурацією. Якщо вам просто потрібно експортувати просту конфігурацію сайту, замість функцій слід використовувати систему управління конфігурацією D8. Ви будете використовувати Особливості в D8 для експорту функціональних пакетів (наприклад, "функція фотогалереї").

Як я щось бачу, це те, що ця ідея полегшує командам розробників роботу на менших частинах сайту. Я поки не збираюся входити в робочий процес, хоча, як і раніше, існує занадто багато невідомих змінних, але я не можу побачити, що він сильно відрізняється від поточної процедури розгортання функцій.

Я не можу допомогти, але думаю, що так, CMI є приголомшливим; але більшість моїх сайтів все ще залишатимуться модулями функцій (хоча і меншою кількістю через те, що не потрібно експортувати ВСІЙ тип вмісту, дозвіл тощо)

— Чапабу
джерело

Хоча я згоден, що функції дещо змінять його роль і (сподіваюся) стануть інструментом для поєднання компонентів конфігурації разом (як фотогалерея, яку ви згадуєте), конфігурація (наскільки я розумію) все ще буде підтримуватися через активний конфігураційний каталог. Таким чином, Особливості можуть вирішувати певний компонент, але те, як керувати робочим процесом каталогу конфігурації в різних середовищах, є справжньою проблемою. Процедура розгортання дещо відрізняється від поточної процедури розгортання функцій насамперед тим, що дані activestore є у db, а сховище даних - файли.

— btmash

... процедура розгортання функцій d7 включає в себе дані datastore в базі даних та сховище даних у файлах. Ми переходимо до обох файлів і просто потрібно переконатися, як це впливає на зміну робочого процесу.

— btmash

Зауважте, що функції дійсно не мають концепції активного зберігання та зберігання даних. Або, принаймні, не послідовно, все залежить від конкретного гачка / речі, з яким він інтегрується. Перегляди за замовчуванням живуть у коді, наприклад, зміни тут же активні (крім кешування), немає керованого процесу розгортання з функціями. Це завжди було однією з головних проблем при використанні функцій для розгортання.

— Бердір

Ти правий. Я не знаю, як у мене змішався модуль конфігурації для D7 з функціями, але я це зробив.

— btmash