Editierbaren Site-Inhalt speichern?

Wir haben eine Django-basierte Website, für die wir einen Teil des Inhalts (Text und Geschäftslogik wie Preispläne) intern problemlos bearbeiten möchten. Daher haben wir beschlossen, ihn außerhalb der Codebasis zu speichern. Normalerweise ist der Grund einer der folgenden:

• Es ist etwas, das nicht-technische Leute bearbeiten wollen. Ein Beispiel ist das Verfassen von Texten für eine Website. Die Programmierer erstellen eine Vorlage mit Text, der standardmäßig "Lorem ipsum ..." lautet, und der eigentliche Inhalt wird später in die Datenbank eingefügt.

• Es ist etwas, das wir schnell ändern möchten, ohne neuen Code bereitstellen zu müssen (was wir derzeit zweimal pro Woche tun). Ein Beispiel wären Funktionen, die den Kunden derzeit zu unterschiedlichen Preisstufen zur Verfügung stehen. Anstatt diese fest zu codieren, lesen wir sie aus der Datenbank.

Die beschriebene Lösung ist flexibel, aber es gibt einige Gründe, warum ich sie nicht mag.

• Da der Inhalt aus der Datenbank gelesen werden muss, entsteht ein Leistungsaufwand .

  Wir verringern dies durch die Verwendung eines Caching-Schemas, dies erhöht jedoch auch die Komplexität des Systems.

• Entwickler, die den Code lokal ausführen, sehen das System in einem deutlich anderen Zustand als in der Produktion. Automatisierte Tests üben das System auch in einem anderen Zustand aus. Situationen wie das Testen neuer Funktionen auf einem Staging-Server werden ebenfalls schwieriger. Wenn der Staging-Server keine aktuelle Kopie der Datenbank hat, kann dies unerwartet von der Produktion abweichen.

  Wir könnten dies abschwächen, indem wir den neuen Status gelegentlich in das Repository übernehmen (z. B. durch Hinzufügen von Datenmigrationen), aber es scheint ein falscher Ansatz zu sein. Ist es?

Irgendwelche Ideen, wie man diese Probleme am besten löst? Gibt es einen besseren Ansatz für den Umgang mit den Inhalten, die ich übersehen habe?

Sie sollten sich bearbeitbare Inhalte als vollständige Funktion vorstellen .

• Eine zusätzliche Komplexität ist offensichtlich erforderlich. Möglicherweise können Sie die statische Ressource nach der Bearbeitung speichern, um Leistungseinbußen zu vermeiden.
• Inhalt ist Daten, also Teil des Systemstatus. Entwickler müssen damit umgehen und denken, dass Benutzer so ziemlich alles tun können, was Ihre Benutzeroberfläche ihnen erlaubt.
• Wenn automatisierte Tests vom Datenbankstatus abhängen, müssen die Tests vor dem Ausführen auch den Datenbankstatus (TestDataBuilders, Fixtures ...) festlegen oder Unit-Tests durchführen (möglicherweise durch Verspotten).

Anstatt Inhalte bearbeitbar zu machen, können Sie diese technischen Mitarbeiter zu einem Teil Ihres Entwicklungsflusses machen. Anstatt zu entwickeln -> bereitzustellen -> Daten zu ändern, können Sie Daten ändern -> entwickeln -> bereitstellen. Vielleicht könnten Sie einige Ideen von statischen Blogging-Plattformen wie Octopress ausleihen .

Dies ist eine gute Aufgabe für Ihre DevOps. :) Sie können Folgendes tun:

1. Legen Sie bearbeitbare Ressourcen in einem separaten Artefakt- / VCS-Repository ab (ich verwende hier die Git-Terminologie).
2. Implementieren Sie Ihren Erstellungs- und Bereitstellungsprozess so, dass diese Ressourcen einfach aus diesem Repository an einen separaten Speicherort auf dem Server abgerufen werden (Sie können eine Konvention für verschiedene Umgebungen festlegen, sodass Sie diesen Speicherort nicht für jede Umgebung separat konfigurieren müssen).
3. Wenn der Benutzer etwas auf der Website ändert, wird die Änderung einfach in einer Ressourcendatei gespeichert. Push to Remote Repository wird bei jeder Änderung asynchron ausgeführt.
4. Um Änderungen bereitzustellen, deaktiviert der Entwickler die Bearbeitungsfunktion und führt seine Änderungen in das Remote-Repository ein. Bei der Produktion zieht er dann die zusammengeführten Dateien aus dem Remote-Repo. Danach kann die Bearbeitungsfunktion wieder aktiviert werden.

Es ist möglich, alles außer der Zusammenführung mit Chef oder einem anderen Tool zu automatisieren, sodass diese Lösung sowohl für Benutzer als auch für Entwickler und SQA komfortabel ist.

Irgendwelche Ideen, wie man diese Probleme am besten löst?

Wir hatten die gleiche Situation. Am Ende haben wir die folgenden Django-Apps verwendet:

• I18N Geschmack von Flatpages
• mit aktiviertem Redactor WYSIWYG-Editor.

Es ist nicht perfekt, aber es gibt Ihnen alles, was Sie brauchen:

• Nicht-Techniker können bearbeiten,
• Keine Codebereitstellung erforderlich.
• Wenn Sie eine Versionskontrolle benötigen, bietet Ihnen die Reversion- App genau das.

Damit Entwickler die gleichen Seiten wie auf dem Produktionssystem haben, exportieren Sie, wenn dies tatsächlich erforderlich ist, von der Produktion in die Entwicklung und testen Sie sie mithilfe von Fixtures.

Gibt es einen besseren Ansatz für den Umgang mit den Inhalten, die ich übersehen habe?

Konzeptionell denke ich, dass Sie auf dem richtigen Weg sind. Fragen Sie sich, ob Sie Ihre eigene Lösung implementieren müssen oder ob Sie mit einer Art CMS leben können. Flatpages ist eine sehr einfache Version davon. Weitere anspruchsvolle CMS zur Verfügung.