Зберігання редагованого вмісту сайту?


9

У нас є веб-сайт на основі Джанго, для якого ми хотіли зробити частину контенту (текст та бізнес-логіку, такі як плани ціноутворення) легко редагувати вдома , і тому ми вирішили зберігати його поза кодовою базою даних. Зазвичай причиною є одна з таких:

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

  • Це те, що ми хочемо швидко змінити без необхідності розгортання нового коду (що ми робимо в даний час два рази на тиждень). Прикладом можуть бути функції, доступні в даний час для клієнтів на різних рівнях ціноутворення. Замість жорсткого кодування їх ми читаємо з бази даних.

Описане рішення є гнучким, але є деякі причини, чому мені це не подобається.

  • Оскільки вміст потрібно читати з бази даних, є ефективність роботи .

    Ми це пом’якшуємо, використовуючи схему кешування, але це також додає певної складності системі.

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

    Ми можемо пом’якшити це, якщо періодично вносити новий стан у сховище (наприклад, додаючи міграцію даних), але це здається неправильним підходом. Є це?

Будь-які ідеї, як найкраще вирішити ці проблеми? Чи є кращий підхід для обробки вмісту, який я оглядаю?


2
Найкращий спосіб вирішити подібні проблеми - це уникнути «паралічу аналізу». Будь-який спосіб, який ви вирішите зробити це, матиме накладні витрати, не додайте більше нічого, не вгадавши про себе.
Nocturno

Про скільки державних дат ми говоримо тут? Кілька кілограмів, мегс?
Аміт Вадхва

Відповіді:


5

Вам слід подумати про редагований вміст як про повну функцію .

  • Певна додаткова складність очевидно потрібна. Можливо, ви можете зберегти статичний ресурс після редагування, щоб уникнути шкоди для продуктивності.
  • Вміст - це дані, тому він є частиною стану системи. Розробники повинні боротися з цим, думаючи, що користувачі можуть зробити майже все, що дозволяє ваш інтерфейс.
  • Якщо автоматичні тести покладаються на стан бази даних, тести також повинні встановити стан бази даних (TestDataBuilders, світильники ...) перед запуском або зробити їх одиничними тестами (можливо, через глузування).

Але замість того, щоб зробити вміст редагованим, ви можете зробити так, щоб технічні люди стали частиною вашої розробки. Замість того, щоб розвивати -> розгортати -> змінювати дані, можна змінити дані -> розробити -> розгорнути. Можливо, ви могли б позичити деякі ідеї у статичних платформ для ведення блогів, таких як Octopress .


0

Це хороше завдання для ваших DevOps. :) Ви можете зробити наступне:

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

Можна автоматизувати все, крім злиття з Chef або будь-яким іншим інструментом, тож це рішення може бути зручним як для користувачів, так і для розробників та SQA.


0

Будь-які ідеї, як найкраще вирішити ці проблеми?

У нас була така сама ситуація. Ми закінчили користуватися такими програмами Django:

Це не ідеально, але дає вам все необхідне:

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

Щоб розробники мали ті самі сторінки, що й у виробничій системі, якщо це фактична вимога, експортуйте з виробництва на розробку та тестуйте за допомогою світильників.

Чи є кращий підхід для обробки вмісту, який я оглядаю?

Концептуально я думаю, що ви на правильному шляху. Запитайте себе, чи потрібно реалізувати власне рішення, чи ви можете жити з якоюсь CMS. Flatpages - це одна дуже проста версія цього. Доступні більш складні CMS .

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.