In che modo le persone gestiscono la gestione della produzione del sistema di gestione dei contenuti?

Question

Mi sto immergendo nelle tecnologie di sviluppo web per divertimento (ya, dovrei uscire di più), e sono un po 'scioccato dalla mancanza di un chiaro supporto per la produzione di staging (cioè sviluppo, test, performance e ambienti di produzione). In realtà il supporto non è la parola; I sistemi di gestione dei contenuti sembrano lavorare attivamente contro gli sforzi per consentire una messa in scena pulita.

Attualmente sto usando Drupal. Ho avuto molto difficoltà a scoprire come la comunità risolve questo problema. La maggior parte dei post che ho visto consigliano di riprodurre i passaggi fatti in fase di sviluppo sul sistema di produzione (leggere questo in realtà ha accorciato la mia vita un po '). Ho anche sentito di spingere i dati di produzione indietro agli sviluppatori in modo che possano aggiungere funzionalità incrementali. Questo non può essere il modo di procedere, e se il cliente non vuole che tu ritiri i dati nel tuo ambiente di sviluppo?

Così alla fine la mia domanda:

Come stai gestire i problemi di produzione messa in scena del mondo reale per un CMS?

io vengo da un background in cui spingere per la produzione si sente come l'invio di persone alla luna, così che io possa bisogno di rilassarsi un po '. Tuttavia, mi interessano ancora le risposte che riguardano il controllo del codice sorgente, il rollback della produzione e il test.

Answer 1

Ho risposto a uno question sulle strategie di distribuzione DB.

C'è anche un question sulla distribuzione del codice.

Dove lavoro stiamo lavorando su una distribuzione Drupal abbastanza grande. Abbiamo approssimativamente la seguente configurazione.

Tutti gli sviluppatori dispongono di una sandbox locale (Drupal + DB). Il codice di commit di un ramo che è condiviso tra tutti gli altri sviluppatori (ci sono circa 15 di noi). Ciò include le modifiche alla configurazione eseguite dalle funzioni di aggiornamento.

Quando gli sviluppatori eseguono una svn, eseguono anche update.php per eseguire qualsiasi modifica alla configurazione localmente.

Abbiamo un sistema di test di sprint che funziona in modo più semplice e può essere utilizzato per il test dell'utente.

Alla fine di uno sprint (noi usiamo mischia), uniamo il ramo in tronco, ed eseguiamo test su questo.

Quindi taggliamo come una versione e la distribuiamo in live (utilizzando Capistrano), infine eseguiamo update.php su live per applicare le modifiche alla configurazione in tempo reale.

Eventuali correzioni di emergenza vengono distribuiti dal tronco di vivere come un punto di rilascio 7.1 ecc

Se vuoi più dettagli quindi si prega di lasciare un commento.

Answer 2

Attualmente sto utilizzando Drupal. Ho avuto molto difficoltà a scoprire come la comunità risolve questo problema.

È uno dei punti deboli di Drupal; In realtà non tratta correttamente questa questione. È particolarmente difficile da risolvere perché gran parte della configurazione di Drupal risiede nel database.

Answer 3

Dopo aver investito alcune settimane a scavalcare la curva di apprendimento di Drupal, la questione "Troppa configurazione è archiviata nel DB" è molto sconcertante se si sta costruendo un sito di qualsiasi complessità.

Dai un'occhiata al lavoro che Development Seed sta facendo per ovviare a questo problema. Stanno guidando lo sviluppo dei moduli Context, Features e Spaces che lavorano insieme per memorizzare i dati di configurazione nei moduli (al di fuori del DB) in modo che possa essere versionato con il codice.