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

41

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

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

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

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

migration 8 version-control btmash
источник
5
Я не совсем согласен с текущими закрытыми голосами. Поскольку CMI является основной темой Drupal 8, я думаю, у нас могут быть хорошие ответы здесь.
mpdonadio
3
Согласен, это очень хороший вопрос. Я считаю, что критическая задача drupal.org/node/1703168 посвящена этой и другим темам и еще не полностью решена, поэтому ответы здесь могут помочь продвинуть эту проблему.
Бердир
Я прошу прощения, если мой вопрос был отрицательным по отношению к инициативе CMI (что не было моим намерением вообще). Я обновил вопрос, чтобы он звучал более нейтрально.
13:00
2
я почти собирался сказать "Вы пробовали особенности". Может быть, "D8" должен идти в названии вопроса? Тег "8" немного невидим.
Donquixote
1
Изменено название, так что вопрос можно увидеть как по тегу, так и по заголовку :)
btmash

Ответы:

19

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

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

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

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

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

Berdir
источник
Постановочный каталог в управлении версиями, я получаю эту часть. Другие части - это то, что мой разум пытается обработать. Поэтому, если кто-то вносит изменения, они копируют свои изменения в промежуточный каталог и фиксируют его. После этого другие разработчики / следующий сервер получают изменения и синхронизируют их с активным каталогом. И промойте и повторите для любой другой цепочки серверов по пути (подготовка, производство и т. Д.). И он всегда проходит через стадию, поэтому переключение каталогов больше не происходит. Это было бы точно?
бтмаш
Да. Не должно быть никакого переключения каталога. Каждое изменение конфигурации должно проходить через процесс импорта, иначе вы можете получить неработающий сайт. Например, список модулей также является конфигурацией. Развертывание этого означает, что модули должны быть установлены / удалены (Примечание: это еще не работает, но есть проблема, чтобы исправить это).
Бердир
Итак, теперь еще больше вопросов (разделенных на 2 комментария) :) Во-первых, вы упомянули модули конфигурации. Таким образом, даже если модуль добавлен в репозиторий и не включен / не отключен, его нужно установить / удалить, чтобы просто сидеть там?
бтмаш
И продолжение: (A) Будет ли механизм для копирования изменений из активного каталога -> подготовка (для упрощения по сравнению с тем, кто входит в каталог конфигурации для этих компонентов - возможно, способ выбора определенных переменных). (B) Будет ли очищен промежуточный каталог после синхронизации изменений от промежуточного положения -> активно? (B1) Если так, то является ли стратегия с точки зрения devops сбросить этот каталог до git pull? (B2) Если нет, то правильно ли предполагать, что во время постановки-> активной синхронизации не должно быть никакого влияния на конфигурацию, которая не изменилась?
бтмаш
Состояние установки модуля - конфигурация. Не сам модуль :) Это то, что вы развертываете. a) Существует пользовательский интерфейс для загрузки tar.gz из активного каталога, один для загрузки указанного tar.gz в промежуточный каталог и один для фактического выполнения импорта, с обзором и изменениями изменений. Б) Я верю, что сейчас он опустошен, но я полагаю, что вы можете легко исправить это с помощью мерзавца. Не уверен, легко проверить. Все эти вещи являются подключаемыми, поэтому может быть немного другая реализация, которая не удаляется. B2) Я этого не понимаю, но думаю, что да.
Бердир
4

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

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

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

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

webflo
источник
1
Пока что я согласен с таким подходом. Я добавил все функции из ссылок в этом посте в команды Drush config-export и config-import. Я надеюсь, что другие присоединятся ко мне и @florian в изучении этого решения для 3 каталогов.
Моше Вейцман
Как вы справляетесь с sites/default/files/config_HASHпапкой config, имеющей суффикс хеша, например config_wNOLcmycPFZCrXJ9wis9dCdSR4lpYILdBsFxSWuK5Hzhcr
therobyouknow
@therobyouknow Возможно переопределить расположение этих папок. Просто посмотрите «Расположение файлов конфигурации сайта». в settings.php я использую следующий фрагмент. Это означает, что конфиг хранится вне корневого каталога Drupals. $ config_directories = array ('active' => '../config/active', 'staging' => '../config/staging',);
webflo
Спасибо @webflo, я видел это. Какая польза от управления базой кода и конфигом отдельно? Я думаю, что это разделение немного искусственное, так как код и конфиг (в yaml) определяют поведение и зависят друг от друга. В Drupal 7 конфигурация в коде (или отслеживаемая Git) была сделана с помощью модуля Features, создающего модуль для каждой конкретной конфигурации, которую необходимо было отслеживать в коде. В Drupal 8 есть Features 3.x, который, как я понимаю, делает то же самое, но использует YAML для хранения конфигурации, и сгенерированные модули не зависят от модуля Features.
therobyouknow
Я думаю, вы меня не так поняли, каталог config все еще находится в git, но мой сайт на Drupal не находится в корне git repo. Сайт хранится / веб. Таким образом, / config и / web находятся на одном уровне.
webflo
2

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

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

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

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

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

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

jonpugh
источник
Это звучит очень похоже на особенности, не так ли? Или есть существенная разница, по которой я скучаю?
Летарион
Это интересный подход, и мне нравится идея. Однако одно из самых больших преимуществ, которое было упомянуто как часть инициативы CMI, - это возможность перемещаться по конфигурации из каталогов конфигурации. И из того, что я вижу, файл settings.php позволяет вам определять, где находятся активные / промежуточные каталоги (т.е. они не должны быть автоматически сгенерированными путями). Следовательно, я думаю, что рабочий процесс с текущей конфигурацией должен быть возможен без необходимости создания функции, как упомянуто выше @Letharion.
бтмаш
2

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

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

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

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

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

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

Chapabu
источник
Хотя я согласен с тем, что функции немного изменят свою роль и (будем надеяться) стать инструментом для объединения компонентов конфигурации (например, упомянутой вами функции фотогалереи), конфигурация (насколько я понимаю) все еще будет поддерживаться через активный каталог конфигурации. Таким образом, компоненты могут решить определенный компонент, но реальным вопросом является управление рабочим процессом каталога конфигурации в разных средах. Процедура развертывания немного отличается от текущей процедуры развертывания функций, поскольку данные ActiveStore находятся в БД, а хранилище данных - файлы.
btmash
... процедура развертывания функций d7 включает данные активного хранилища в базе данных и хранилище данных в файлах. Мы переходим к обоим файлам, и нам просто нужно убедиться, как это влияет на сдвиг в рабочем процессе.
бтмаш
Обратите внимание, что функции действительно не имеют понятия активного и хранилища данных / промежуточного хранения. Или, по крайней мере, непоследовательный, все зависит от конкретного крючка / вещи, с которой он интегрируется. Представления по умолчанию живут в коде, например, изменения активны немедленно (кроме кэширования), нет контролируемого процесса развертывания с функциями. Это всегда было одной из основных проблем при использовании функций для развертываний.
Бердир
Вы правы. Я не знаю, как я перепутал модуль конфигурации для D7 с функциями, но я сделал.
btmash