Stockage du contenu du site modifiable?

Nous avons un site Web basé sur Django pour lequel nous voulions rendre une partie du contenu (texte et logique métier tels que les plans tarifaires) facilement modifiable en interne , et nous avons donc décidé de le stocker en dehors de la base de code. Habituellement, la raison est l'une des suivantes:

• C'est quelque chose que les non-techniciens veulent modifier. Un exemple est la rédaction pour un site Web - les programmeurs préparent un modèle avec du texte par défaut "Lorem ipsum ...", et le contenu réel est inséré plus tard dans la base de données.

• C'est quelque chose que nous voulons pouvoir changer rapidement, sans avoir à déployer de nouveau code (ce que nous faisons actuellement deux fois par semaine). Un exemple serait les fonctionnalités actuellement disponibles pour les clients à différents niveaux de tarification. Au lieu de les coder en dur, nous les lisons dans la base de données.

La solution décrite est flexible mais il y a quelques raisons pour lesquelles je ne l'aime pas.

• Étant donné que le contenu doit être lu à partir de la base de données, il existe une surcharge de performances .

  Nous atténuons cela en utilisant un schéma de mise en cache, mais cela ajoute également une certaine complexité au système.

• Les développeurs qui exécutent le code localement voient le système dans un état sensiblement différent par rapport à la façon dont il s'exécute en production. Les tests automatisés exercent également le système dans un état différent. Des situations telles que le test de nouvelles fonctionnalités sur un serveur de transfert deviennent également plus délicates - si le serveur de transfert n'a pas de copie récente de la base de données, elle peut différer de façon inattendue de la production.

  Nous pourrions atténuer cela en validant occasionnellement le nouvel état dans le référentiel (par exemple en ajoutant des migrations de données), mais cela semble être une mauvaise approche. C'est ça?

Des idées sur la meilleure façon de résoudre ces problèmes? Existe-t-il une meilleure approche pour gérer le contenu que je néglige?

Vous devez considérer le contenu modifiable comme une fonctionnalité complète .

• Une complexité supplémentaire est évidemment nécessaire. Vous pouvez peut-être stocker la ressource statique après la modification afin d'éviter des dommages aux performances.
• Le contenu est des données, il fait donc partie de l'état du système. Les développeurs doivent y faire face en pensant que les utilisateurs peuvent faire à peu près tout ce que votre interface utilisateur leur permet.
• Si les tests automatisés reposent sur l'état de la base de données, les tests doivent également définir l'état de la base de données (TestDataBuilders, fixtures ...) avant de s'exécuter, ou en faire des tests unitaires (peut-être par le biais d'une simulation).

Mais, au lieu de rendre le contenu modifiable, vous pouvez intégrer ces techniciens à votre flux de développement. Au lieu de développer -> déployer -> modifier les données, vous pouvez modifier les données -> développer -> déployer. Vous pourriez peut-être emprunter des idées à des plateformes de blogs statiques comme Octopress .

C'est une bonne tâche pour vos DevOps. :) Vous pouvez effectuer les opérations suivantes:

1. Mettez les ressources modifiables dans un référentiel d'artefact / VCS séparé (j'utiliserai la terminologie Git ici).
2. Implémentez votre processus de génération et de déploiement de sorte que ces ressources soient simplement extraites de ce référentiel vers un emplacement séparé sur le serveur (vous pouvez établir une convention pour différents environnements afin que vous n'ayez pas besoin de configurer cet emplacement séparément pour chacun).
3. Lorsque l'utilisateur modifie quelque chose sur le site Web, la modification est simplement enregistrée dans un fichier de ressources. Le push vers le référentiel distant est exécuté de manière asynchrone à chaque changement.
4. Pour déployer les modifications, le développeur désactive la fonctionnalité d'édition et fusionne ses modifications dans le référentiel distant. Puis, en production, il extrait les fichiers fusionnés du repo distant. Après cela, la fonctionnalité d'édition peut être réactivée.

Il est possible d'automatiser tout sauf la fusion avec Chef ou tout autre outil, cette solution peut donc être confortable pour les utilisateurs, les développeurs et SQA.

Des idées sur la meilleure façon de résoudre ces problèmes?

Nous avons eu la même situation. Nous avons fini par utiliser les applications Django suivantes:

• Saveur I18N des pages plates
• avec l' éditeur Redactor WYSIWYG activé.

Ce n'est pas parfait, mais il vous donne tout ce dont vous avez besoin:

• les personnes non techniques peuvent éditer,
• aucun déploiement de code n'est nécessaire.
• Si vous avez besoin d'un contrôle de version, l' application de réversion vous donnera exactement cela.

Pour que les développeurs aient accès aux mêmes pages que sur le système de production, si c'est une exigence réelle, exportez de la production au développement et testez à l'aide de fixtures.

Existe-t-il une meilleure approche pour gérer le contenu que je néglige?

Conceptuellement, je pense que vous êtes sur la bonne voie. Demandez-vous si vous devez mettre en œuvre votre propre solution ou si vous pouvez vivre avec une sorte de CMS. Flatpages en est une version très simple. Des CMS plus sophistiqués sont disponibles.