Хранить редактируемый контент сайта?

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

• Это то, что нетехнические люди хотят редактировать. Одним из примеров является копирайтинг для веб-сайта - программисты готовят шаблон с текстом, который по умолчанию имеет значение «Lorem ipsum ...», а реальный контент позже вставляется в базу данных.

• Это то, что мы хотим иметь возможность быстро менять без необходимости развертывания нового кода (что мы в настоящее время делаем два раза в неделю). Примером могут служить функции, доступные в настоящее время клиентам на разных уровнях ценообразования. Вместо того, чтобы жестко их кодировать, мы читаем их из базы данных.

Описанное решение является гибким, но есть некоторые причины, по которым оно мне не нравится.

• Поскольку содержимое должно быть прочитано из базы данных, это приводит к снижению производительности .

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

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

  Мы могли бы смягчить это, периодически передавая новое состояние в хранилище (например, добавляя перенос данных), но это кажется неправильным подходом. Это?

Есть идеи, как лучше всего решить эти проблемы? Есть ли лучший подход для обработки контента, который я пропускаю?

Вы должны думать о редактируемом контенте как о полной функции .

• Некоторая дополнительная сложность явно необходима. Возможно, вы могли бы сохранить статический ресурс после редактирования, чтобы избежать снижения производительности.
• Контент - это данные, поэтому он является частью состояния системы. Разработчики должны иметь дело с этим, думая, что пользователи могут делать практически все, что позволяет им ваш пользовательский интерфейс.
• Если автоматические тесты основаны на состоянии базы данных, тесты также должны установить состояние базы данных (TestDataBuilders, fixtures ...) перед запуском или сделать их модульными тестами (возможно, путем имитации).

Но вместо того, чтобы сделать контент редактируемым, вы могли бы сделать технарей частью вашего процесса разработки. Вместо разработки -> развернуть -> изменить данные, вы можете изменить данные -> разработать -> развернуть. Возможно, вы могли бы позаимствовать некоторые идеи у статических блоговых платформ, таких как Octopress .

Это хорошая задача для ваших DevOps. :) Вы можете сделать следующее:

1. Поместите редактируемые ресурсы в отдельный репозиторий артефактов / VCS (здесь я буду использовать терминологию Git).
2. Реализуйте процесс сборки и развертывания, чтобы эти ресурсы просто извлекались из этого репозитория в отдельное расположение на сервере (вы можете установить некоторые соглашения для разных сред, поэтому вам не нужно будет настраивать это расположение отдельно для каждого из них).
3. Когда пользователь что-то меняет на веб-сайте, это изменение просто сохраняется в файле ресурсов. Push в удаленный репозиторий выполняется асинхронно при каждом изменении.
4. Для развертывания любых изменений разработчик отключает функцию редактирования и объединяет свои изменения в удаленном хранилище. Затем на производстве он извлекает объединенные файлы из удаленного репо. После этого функциональность редактирования можно снова включить.

Можно автоматизировать все, кроме слияния с Chef или любым другим инструментом, поэтому это решение может быть удобным как для пользователей, так и для разработчиков и SQA.

Есть идеи, как лучше всего решить эти проблемы?

У нас была такая же ситуация. В итоге мы использовали следующие приложения Django:

• I18N аромат плоских страниц
• с включенным редактором WYSIWYG Redactor .

Это не идеально, но дает вам все, что вам нужно:

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

Чтобы разработчики работали с теми же страницами, что и в производственной системе, если это действительно необходимо, экспортируйте их из производства в разработку и тестируйте с помощью приспособлений.

Есть ли лучший подход для обработки контента, который я пропускаю?

Концептуально, я думаю, что вы на правильном пути. Спросите себя, нужно ли вам реализовать собственное решение или вы можете жить с какой-то CMS. Плоские страницы - одна очень простая версия этого. Доступны более сложные CMS .