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

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

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

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

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

40 голосов | спросил btmash 13 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 13 Sep 2013 20:32:37 +0400 2013, 20:32:37

4 ответа


19

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

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

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

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

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

ответил Berdir 19 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 19 Sep 2013 15:50:25 +0400 2013, 15:50:25
4

Великий ответил до сих пор. Спасибо всем!

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

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

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

ответил webflo 31 +04002013-10-31T17:03:42+04:00312013bEurope/MoscowThu, 31 Oct 2013 17:03:42 +0400 2013, 17:03:42
2

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

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

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

Процесс развертывания будет выглядеть следующим образом:

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

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

ответил jonpugh 19 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 19 Sep 2013 01:24:29 +0400 2013, 01:24:29
2

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

Как массивный поклонник Особенности , я предлагаю следить за Особенности - воплощение модуля D8.

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

  Для Drupal 8 для интеграции с новой системой управления конфигурацией планируется

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

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

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

ответил Chapabu 19 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 19 Sep 2013 12:34:34 +0400 2013, 12:34:34

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132