Memorizzazione di contenuto del sito modificabile?

Question

Memorizzazione di contenuto del sito modificabile?

#1 da (5 voti)
#2 da (0 voti)
#3 da (0 voti)

9

Abbiamo un sito web basato su Django per il quale abbiamo voluto rendere alcuni dei contenuti (testo e business logic come i piani tariffari) facilmente modificabili in-house , e così abbiamo deciso di archiviare fuori dalla base di codice. Di solito il motivo è uno dei seguenti:

È qualcosa che persone non tecniche desidera modificare. Un esempio è il copywriting per un sito Web: i programmatori preparano un modello con testo predefinito "Lorem ipsum ..." e il contenuto reale viene inserito successivamente nel database.
È qualcosa che vogliamo essere in grado di modificare rapidamente, senza la necessità di distribuire nuovo codice (che attualmente facciamo due volte a settimana). Un esempio potrebbe 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 overhead delle prestazioni .

La attenuiamo 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 diverso in modo significativo rispetto a come viene eseguito sulla produzione. I test automatici inoltre esercitano il sistema in uno stato diverso. Anche situazioni come testare nuove funzionalità su un server di staging sono più complicate: se il server di staging non ha una copia recente del database, può essere inaspettatamente diverso dalla produzione.

Potremmo attenuarlo inserendo occasionalmente il nuovo stato nel repository (ad es. aggiungendo migrazioni di dati), ma sembra un approccio errato. È?

Qualche idea sul modo migliore per risolvere questi problemi? C'è un approccio migliore per gestire il contenuto che sto trascurando?

repository django content-management

posta hmp 11.05.2014 - 01:14

fonte

3 risposte

Leggi altre domande sui tag repository django content-management

Duck typing, validazione dei dati e programmazione assertiva in Python Quale problema pratico deriva dalla mancanza di macro igienici in Clojure?

score 5 · Answer 1

Dovresti pensare ai contenuti modificabili come una funzione completa .

È ovviamente necessaria una maggiore complessità. Forse potresti archiviare la risorsa statica dopo la modifica per evitare danni alle prestazioni.
Il contenuto è dati, quindi fa parte dello stato del sistema. Gli sviluppatori devono occuparsene pensando che gli utenti possano fare praticamente tutto ciò che l'interfaccia utente gli consente.
Se i test automatici si basano sullo stato del database, i test devono anche impostare lo stato del database (TestDataBuilders, fixtures ...) prima dell'esecuzione, o renderli test unitari (magari attraverso il mocking).

Tuttavia, invece di rendere modificabili i contenuti, potresti rendere le persone tecniche parte del tuo flusso di sviluppo. Invece di sviluppare - > deploy - > altera i dati, potresti alterare i dati - > sviluppare - > distribuire. Forse potresti prendere in prestito alcune idee dalle piattaforme di blogging statiche come Octopress .

score 0 · Answer 2

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

Metti risorse modificabili in repository di dati / artefatti separati (utilizzerò la terminologia Git qui).
Implementa il processo di generazione e distribuzione in modo che queste risorse vengano semplicemente estratte da quel repository in una posizione separata sul server (è possibile stabilire alcune convenzioni per ambienti diversi in modo da non dover configurare questa posizione separatamente per ciascuna di esse). / li>
Quando l'utente cambia qualcosa sul sito web, la modifica viene semplicemente salvata nel file di risorse. Il push sul repository remoto viene eseguito in modo asincrono su ogni modifica.
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.

score 0 · Answer 3

Any ideas how best to solve these problems?

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

Aroma I18N di pagine flat
con l'editor Redactor WYSIWYG abilitato.

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

le persone non tecniche possono modificare,
non è necessaria la distribuzione del codice.
Se hai bisogno del controllo della versione, l'app reversione ti darà proprio questo.

Per fare in modo che gli sviluppatori sperimentino le stesse pagine del sistema di produzione, se questo è un requisito reale, esporta dalla produzione allo sviluppo e prova usando le fixture.

Is there a better approach for handling the content that I'm overlooking?

Concettualmente, penso che tu sia sulla strada giusta. Chiediti se è necessario implementare la propria soluzione o se si può vivere con una sorta di CMS. Flatpages è una versione molto semplice di questo. Sono disponibili altri CMS sofisticati .