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

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

Лучшее, что мы в комнате смогли выяснить (частично на основе презентации в DrupalCon Portland), было:

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

И используйте файл settings.php для обращения к активной / промежуточной директории между двумя средами. Тем не менее, хотя выяснение рабочего процесса развертывания с одного сервера на другой было сложным, но выполнимым, каков рекомендуемый рабочий процесс из нескольких локальных сред (т.е. нескольких разработчиков) в dev (или между собой)? Возможной проблемой будет каждый член команды Будет ли общий доступ к той же или аналогичной среде, так как могут происходить изменения на компьютере одного из партнеров?

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

Пытаясь сохранить его кратким, постараемся расширить на основе вопросов / когда упомянутая проблема будет решена с официальным ответом.

Итак, во-первых, факты ...

• Как уже упоминалось, есть активный и промежуточный каталог. Active полностью управляется Drupal, вносить изменения непосредственно там (прямые или косвенные путем переключения в другое место) не поддерживается.
• Постановка - это когда Drupal ищет конфигурацию для импорта и не заботится об этом.
• Процесс импорта важен, изменения конфигурации могут определенным образом повлиять на сайт и должны быть проверены на правильность. Вы не можете изменить тип поля текстового поля на ссылку на сущность, например, которая просто не работает.
• Импорт конфигурации всегда должен выполняться во всех конфигурациях, вы не можете импортировать одно представление или тип узла. Это было опробовано, но попытка справиться с зависимостями, удалить / переименовать и т. Д. Привела к очень сложной системе, и она не работала.
• Единственный способ переустановить конфигурацию по умолчанию, это переустановить этот модуль. Это означает, что он сначала попытается удалить все настройки (например, поля). Так что это не совсем вариант. Вручную, конкретные изменения в функциях обновления возможны, но я думаю, что это слишком утомительно для этого.
• Как описывает модуль функций, он будет ориентирован на обеспечение многократного использования функциональности, а не на непрерывное развертывание конфигурации. Это то, для чего он был разработан в первую очередь.

Учитывая это, рекомендация прямо сейчас состоит в том, чтобы поместить промежуточный каталог в систему управления версиями. Каждый разработчик получает полный контроль над тем, что он помещает туда, копируя весь активный каталог или просто конкретный файл конфигурации. Изменения промежуточного каталога затем фиксируются, передаются в производство и запускается импорт конфигурации (в пользовательском интерфейсе или с помощью drush).

Отлично ответили пока. Спасибо вам всем!

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

У нас есть три активные папки, подготовка и экспорт. Разработчики сбрасывают их на экспорт. Я не хочу держать это в стадии. Я думаю, что с ним легче работать, когда общая конфигурация не хранится непосредственно в промежуточной папке. Это просто сруб, у меня нет никаких серьезных фактов об этом ...

Наш текущий шаблон проекта drupal 8 доступен на github. Я также написал несколько удобных команд drush для ускорения работы devleoper. Ручное копирование с активного на экспорт не требуется.

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

Я еще не пробовал, но я планирую создать пользовательский модуль, который содержит файлы конфигурации «по умолчанию», содержащие только конфигурацию, которая мне нужна. Я считаю, что другие модули могут содержать конфиги, которые переопределяют другие модули. (Если нет, это должно быть сделано возможным).

Я думаю, что вы должны оставить папку конфигурации в покое. Игнорируй это. Он автоматически генерируется при установке из всех файлов конфигурации отдельных модулей. Путь длинный и случайный. Если бы вы хранили все это в репо, вам понадобилось бы отдельное репо, и вы бы взяли с собой тонны стандартных, ненужных файлов конфигурации.

Размещение конфигурации в пользовательском модуле делает его частью вашей основной базы кода.

Процесс развертывания будет:

1. Git pull или что-то еще, чтобы получить новые файлы.
2. Очистить кеши.
3. Сброс настроек по умолчанию. (Из файлов вашего пользовательского модуля)

Вы можете создавать собственные модули (со своими собственными настройками) для каждой среды, если хотите.

Примечание: я ценю, что это не самый точный ответ по отношению к вопросу, но я все равно поставил его здесь, и я вернусь и отредактирую / удалю, как только у функций будет релиз 8.x и пыль поселились немного больше. Это было слишком много для комментария, и я хотел получить свои £ 0,02 :-)

Как большой поклонник возможностей , я бы посоветовал следить за воплощением D8 модуля Features .

Взято со страницы проекта

3. Особенности версии планируется для интеграции Drupal 8 с новой системой управления конфигурацией. Если вам просто необходимо экспортировать простую конфигурацию сайта, вместо функций следует использовать систему управления конфигурацией D8. Вы будете использовать Функции в D8 для экспорта связанных функций (например, «функция фотогалереи»).

Так я вроде вижу в том , что эта идея делает его более легким для Дев команд для работы на более мелкие части сайта. Я пока не собираюсь вдаваться в рабочий процесс, поскольку в нем все еще слишком много неизвестных переменных, но я не вижу, чтобы это ТОЧНО отличалось от текущей процедуры развертывания компонентов.

Я не могу не думать, что да, CMI потрясающий; но большинство моих сайтов по-прежнему будут содержать модули функций (хотя и в меньшем количестве из-за того, что не нужно экспортировать КАЖДЫЙ тип контента, разрешения и т. д.)