Настройка промежуточного рабочего процесса с Netlify CMS - PullRequest
0 голосов
/ 07 сентября 2018

У меня есть сайт Gatsby на Gitlab, развернутый в Netlify и использующий Netlify-CMS. Netlify позволяет перенести сайт в разные филиалы, и каждый из них размещен на отдельном URL. Например, у моего текущего сайта есть ветвь production, развернутая в example.netlify.com, и промежуточная ветвь, развернутая в staging--example.netlify.com.

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

Из документов .

Примечание: где бы вы ни работали с Netlify CMS - работает ли локально, в промежуточной среде или на опубликованном сайте - всегда извлекать и фиксировать файлы в вашем размещенном хранилище (например, на GitHub), на ветви, которую вы настроили в вашей Netlify CMS файл config.yml. Это означает, что содержимое, полученное в интерфейсе администратора, будет сопоставьте содержимое в хранилище, которое может отличаться от вашего локально работающий сайт. Это также означает, что контент сохранен с помощью администратора Пользовательский интерфейс будет сохранен непосредственно в хранилище, даже если вы работаете пользовательский интерфейс локально или в стадии.

Из конфигурации проекта (config.yml), используемой Netlify CMS:

backend:
  name: git-gateway
  branch: production

Так что в данный момент я могу вносить изменения в структуру сайта и делать их доступными только при подготовке, однако нет механизма, позволяющего вносить изменения содержимого и делать их доступными только локально или только при подготовке ,

Один вариант, который я вижу, заключается в том, чтобы развертывать разные файлы config.yml для каждого развертывания (и использовать отдельный файл локально), поэтому при локальном использовании CMS я устанавливаю ветвь на dev, а при подготовке и производство Я бы установил ветку на staging и production соответственно. Предполагая, что расположение контента, отредактированного Netlify-CMS, является изолированным, это должно упростить продвижение изменений контента с staging на production.

Это лучший подход?

1 Ответ

0 голосов
/ 10 сентября 2018

Похоже, что в настоящее время, если вы не используете Github, который поддерживает Редакционный рабочий процесс , вы сами по себе.

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

  • dev При локальном запуске на localhost
  • staging В Netlify добавлена ​​промежуточная ветвь в качестве дополнительного развертывания ветки.
  • производство Производственная ветвь добавлена ​​в Netlify как производственная ветвь.

Если бы мы не использовали Netlify CMS, это было бы все, что нам нужно. Мы могли бы развиваться локально и переходить к поэтапному внедрению, когда мы хотели сделать изменения доступными, а затем продвигаться путем объединения промежуточного этапа в производство и продвижения к производственному отделу, когда эти изменения готовы.

Однако во всех этих средах будет использоваться один и тот же config.yml, то есть все три будут загружаться и вносить изменения в одну и ту же ветку - какую бы ветку вы не указали в качестве значения для branch.

Необходим способ изолировать изменения содержимого в каждой среде, чтобы изменения, вносимые в разработку, вносились в ветку dev, изменения, вносимые при подготовке, вносились в ветку staging, а изменения, вносимые в производство, сделано в production ветке.

Это может быть достигнуто путем развертывания среды config.yml для каждой удаленной среды и установки по умолчанию ветки dev в разработке. Вероятно, самый простой способ сделать это - использовать шаг перед сборкой, чтобы заполнить поле branch вашего config.yml именем текущей ветви.

На мой взгляд, это довольно неудовлетворительное решение, и оно настолько распространено, что его следует использовать в Netlify CMS из коробки. Я открыл вопрос здесь .

...