Memorizzare contenuti modificabili del sito?

Abbiamo un sito Web basato su Django per il quale volevamo rendere parte del contenuto (testo e logica aziendale come i piani tariffari) facilmente modificabili internamente , quindi abbiamo deciso di archiviarlo al di fuori della base di codice. Di solito il motivo è uno dei seguenti:

• È qualcosa che le persone non tecniche vogliono modificare. Un esempio è il copywriting per un sito Web: i programmatori preparano un modello con testo che per impostazione predefinita è "Lorem ipsum ..." e il contenuto reale viene inserito successivamente nel database.

• È qualcosa che vogliamo poter cambiare rapidamente, senza la necessità di distribuire un nuovo codice (cosa che attualmente facciamo due volte a settimana). Un esempio potrebbero essere le funzionalità attualmente disponibili per i clienti a diversi livelli di prezzo. Invece di codificarli, li leggiamo dal database.

La soluzione descritta è flessibile ma ci sono alcuni motivi per cui non mi piace.

• Poiché il contenuto deve essere letto dal database, esiste un sovraccarico di prestazioni .

  Lo mitigiamo utilizzando uno schema di memorizzazione nella cache, ma ciò aggiunge anche una certa complessità al sistema.

• Gli sviluppatori che eseguono il codice localmente vedono il sistema in uno stato significativamente diverso rispetto a come viene eseguito in produzione. I test automatizzati esercitano anche il sistema in uno stato diverso. Anche situazioni come testare nuove funzionalità su un server di gestione temporanea diventano più complicate: se il server di gestione temporanea non ha una copia recente del database, può essere inaspettatamente diverso dalla produzione.

  Potremmo mitigarlo affidando il nuovo stato al repository di tanto in tanto (ad esempio aggiungendo migrazioni di dati), ma sembra un approccio sbagliato. È?

Qualche idea su come risolvere al meglio questi problemi? Esiste un approccio migliore per gestire il contenuto che sto trascurando?

Dovresti pensare al contenuto modificabile come una funzionalità completa .

• È ovviamente necessaria una certa complessità aggiuntiva. Forse potresti archiviare la risorsa statica dopo la modifica per evitare danni alle prestazioni.
• Il contenuto è costituito da dati, quindi fa parte dello stato del sistema. Gli sviluppatori devono occuparsene pensando che gli utenti possano fare praticamente tutto ciò che la tua interfaccia utente consente loro.
• Se i test automatizzati si basano sullo stato del database, i test devono anche impostare lo stato del database (TestDataBuilders, dispositivi ...) prima di eseguirli o renderli test unitari (magari tramite derisione).

Ma, invece di rendere modificabile il contenuto, potresti rendere le persone tecniche parte del tuo flusso di sviluppo. Invece di sviluppare -> distribuire -> modificare i dati, è possibile modificare i dati -> sviluppare -> distribuire. Forse potresti prendere in prestito alcune idee da piattaforme di blog statici come Octopress .

Questo è un buon compito per i tuoi DevOps. :) Puoi fare quanto segue:

1. Metti le risorse modificabili in repository artefatto / VCS separato (userò la terminologia Git qui).
2. Implementa il tuo processo di compilazione e distribuzione in modo che queste risorse vengano semplicemente estratte da quel repository per separare la posizione sul server (puoi stabilire delle convenzioni per ambienti diversi, quindi non dovrai configurare questa posizione separatamente per ognuna).
3. Quando l'utente modifica qualcosa sul sito Web, la modifica viene semplicemente salvata nel file di risorse. Il push nel repository remoto viene eseguito in modo asincrono su ogni modifica.
4. Per distribuire eventuali modifiche, lo sviluppatore disabilita la funzionalità di modifica e unisce le sue modifiche al repository remoto. Quindi, in produzione, estrae i file uniti dal repository remoto. Successivamente, è possibile riattivare la funzionalità di modifica.

È possibile automatizzare tutto tranne l'unione con Chef o qualsiasi altro strumento, quindi questa soluzione può essere comoda sia per utenti, sviluppatori e SQA.

Qualche idea su come risolvere al meglio questi problemi?

Abbiamo avuto la stessa situazione. Abbiamo finito per usare le seguenti app Django:

• Sapore I18N di pagine piatte
• con l' editor Redactor WYSIWYG abilitato.

Non è perfetto, ma ti dà tutto ciò di cui hai bisogno:

• le persone non tecniche possono modificare,
• nessuna distribuzione di codice necessaria.
• Se hai bisogno del controllo della versione, l' app di inversione ti darà proprio questo.

Per fare in modo che gli sviluppatori sperimentino le stesse pagine del sistema di produzione, se questo è un vero requisito, esportare dalla produzione allo sviluppo e testare utilizzando dispositivi.

Esiste un approccio migliore per gestire il contenuto che sto trascurando?

Concettualmente, penso che tu sia sulla buona strada. Chiediti se devi implementare la tua soluzione o se puoi vivere con una sorta di CMS. Flatpages ne è una versione molto semplice. Sono disponibili CMS più sofisticati .