Каков рекомендуемый рабочий процесс для настройки миграции (CMI) из dev -> stage -> производство?
Несколько месяцев назад у нас был drupalcamp, и кто-то спросил об управлении развертываниями с новой конфигурацией (CMI). Один из возможных идеальных рабочих процессов будет включать сохранение конфигурации в управлении версиями и возможность переноса конфигурации между членами команды.
Лучшее, что мы в комнате смогли выяснить (частично на основе презентации в DrupalCon Portland), было:
- Сообщить об управлении версиями, чтобы игнорировать каталог активных конфигураций.
- Скопируйте всю конфигурацию в промежуточный каталог и зафиксируйте контроль версий.
И используйте settings.php, чтобы перевернуть активный /промежуточный каталог между двумя средами. Однако при вычислении рабочего процесса развертывания с одного сервера на другой был сложным, но выполнимым, каков предлагаемый рабочий процесс из нескольких локальных сред (т.е. нескольких разработчиков) в dev (или между собой). Возможной проблемой может быть каждый член команды будет делиться одной и той же или подобной средой, так как будут изменения на машине одного товарища по команде?
4 ответа
Немного поговорив с поддерживающими CMI, обсуждение того, что является наилучшим подходом, еще не закончено, но в данный момент самое главное.
Попытавшись сохранить его на время, попытайтесь расширить на основе вопросов /когда проблема с ссылкой будет разрешена с официальным ответом.
Итак, во-первых, факты ...
- Как уже упоминалось, есть активный и промежуточный каталог. Active полностью управляется Drupal, поэтому внесение изменений прямо (прямое или косвенное путем переключения в другое место) не поддерживается.
- Staging - это где Drupal ищет конфигурацию для импорта, а в противном случае это не заботится.
- Процесс импорта важен, изменения конфигурации могут повлиять на сайт определенным образом и должны быть проверены на достоверность. Например, вы не можете изменить тип поля текстового поля на ссылку сущности, которая просто не работает.
- Импорт конфигурации всегда необходимо запускать в конфигурации all , вы не можете импортировать один вид или тип узла. Он был опробован, но, пытаясь справиться с зависимостями, удаляет /переименовывает и т. Д., Приводит к очень сложной системе и не работает.
- Единственный способ переустановки конфигурации по умолчанию - переустановка этого модуля. Это означает, что сначала попробуйте удалить всю конфигурацию (например, поля). Так что это не вариант. В ручном режиме конкретные изменения в функциях обновления возможны, но слишком утомительны для этого, я думаю.
- Как описывает модуль функций, он будет сфокусирован на предоставлении повторно используемых функций, а не на непрерывном развертывании конфигурации. Это то, для чего он был разработан в первую очередь.
Учитывая, что сейчас рекомендация заключается в том, чтобы поставить промежуточный каталог в управление версиями. Каждый разработчик имеет полный контроль над тем, что он там делает, либо путем копирования всего активного каталога, либо только определенного файла конфигурации. Затем изменяются изменения промежуточного каталога, переносятся в производство и запускается импорт конфигурации (в пользовательском интерфейсе или с помощью 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
Я еще не пробовал, но мой план состоит в создании настраиваемого модуля, который содержит файлы конфигурации по умолчанию, содержащие только конфигурацию, о которой я забочусь. Я считаю, что другие модули могут содержать конфигурации, которые переопределяют другие модули. (Если это не должно быть сделано).
Я думаю, что вы должны оставить папку config в одиночку. Игнорируй это. Он автоматически генерируется при установке из всех конфигурационных файлов отдельных модулей. Путь длинный и случайный. Если вы сохранили все это в репо, вам понадобится отдельное репо, и вы будете нести вместе с ним тонны стандартных, ненужных конфигурационных файлов.
Вставка конфига в пользовательский модуль делает его частью вашей основной базы.
Процесс развертывания будет выглядеть следующим образом:
- Git pull или что-то еще, чтобы получать новые файлы.
- Очистить кеши.
- Сбросить конфигурацию по умолчанию. (Из файлов вашего пользовательского модуля)
Вы можете создавать собственные модули (с собственной конфигурацией) для каждой среды, если хотите.
Примечание: Я ценю, что это не ответ в строгом смысле по отношению к вопросу, но я все равно поставил его здесь Я пересматриваю и редактирую /удаляю, как только функции имеют версию 8.x, и пыль уселась еще немного. Это было слишком большим для комментариев, и я хотел получить свой 0,02 в: -)
Как массивный поклонник Особенности , я предлагаю следить за Особенности - воплощение модуля D8.
Снято с страницы проекта
Для Drupal 8 для интеграции с новой системой управления конфигурацией планируетсяверсия 3.x. Если вам просто нужно экспортировать простая конфигурация сайта, система управления конфигурацией D8 следует использовать вместо функций. Вы будете использовать функции в D8 для экспорт в комплекте (например, «функция фотогалереи»).
Способ, которым я kinda видит, что эта идея упрощает работу dev team для более мелких частей сайта. Я не собираюсь идти в рабочий процесс, хотя, поскольку все еще слишком много неизвестных переменных, но я не вижу, чтобы это было сильно отличается от текущей процедуры развертывания функций.
Я не могу не думать, да, CMI потрясающий; но большинство моих сайтов по-прежнему получат модули функций (хотя и меньшую сумму из-за отсутствия необходимости экспортировать КАЖДЫЙ тип контента, разрешение и т. д.)