Come gestisco lo sviluppo collaborativo su un sito Drupal?

Lavoro con un altro sviluppatore su un sito Drupal. Abbiamo faticato a trovare un buon modo per lavorare su diverse parti del sito allo stesso tempo senza intralciarci l'un l'altro. Abbiamo provato a lavorare sulla stessa istanza di sviluppo del sito, ma spesso facciamo un passo avanti a vicenda o abbattiamo il sito con un codice errato, rendendo impossibile per l'altro continuare a lavorare fino a quando non viene risolto. Quindi siamo passati a istanze di sviluppo separate. Ma ora è un grosso problema unire il nostro lavoro in una singola istanza del sito. Fondamentalmente finiamo per rifare tutto su una copia condivisa.

Il problema più grande che abbiamo ora è come unire le modifiche al database e come possiamo includere il database nel nostro sistema di controllo del codice sorgente? I file sono facili, basta seguirli tutti (usiamo git) e unire il nostro lavoro, risolvendo i conflitti dove necessario. Ma questo non funziona davvero con il database. Possiamo prendere un dump SQL e includerlo nel nostro repository git, ma non possiamo davvero unire i database. Il modulo Caratteristiche aiuta un po ', permettendoci di esportare parte del nostro database in codice che può quindi essere aggiornato e unito. Tuttavia, nemmeno vicino a tutto supporta le funzionalità. Così...

• Quali passi possiamo prendere per unire facilmente le modifiche al nostro database?

• Come dovremmo versione del database (mettere un file di dump in git un buon modo per farlo)?

• Ci sono moduli disponibili che aiutano con alcuni di questi problemi?

• Oppure, siamo bloccati a lavorare sulla stessa copia del sito? (per favore, quindi no)

Modifica: Nei commenti abbiamo discusso di quali cose non possono essere esportate con le caratteristiche e una di queste era la tassonomia. C'è un'altra domanda che si occupa di questo .

Si tratta di una modifica del flusso di lavoro ma è necessario abituarsi a lavorare su un nuovo dump del DB live. Esistono tre modi per ottenere modifiche nel DB.

1. Caratteristiche. Questo non funzionerà per tutto ma per molte cose di cui hai bisogno.
2. ganci di aggiornamento. Quando le funzionalità non funzionano, puoi codificare le cose in un hook di aggiornamento di un modulo che possiedi.
3. Modifiche manuali. Usa con parsimonia. Alcune cose non vengono naturalmente alle funzionalità o agli hook di aggiornamento e sono semplicemente molto più facili da eseguire manualmente. Questa è l'ultima risorsa ma a volte è l'unica via piratica.

Se puoi. Più volte al giorno ottieni un nuovo dump e testa la tua build, dovresti avere meno problemi di integrazione.

Ho risposto a una domanda simile e la modificherò leggermente per rispondere alla tua domanda qui. Il mio suggerimento di root è di avere un server di sviluppo / gestione temporanea in cui le modifiche al codice vengono verificate utilizzando un sistema di integrazione continua su base frequente (ad esempio, ogni 5 minuti). Pertanto, sul tuo computer locale, lavori solo su una richiesta di funzionalità / segnalazione di bug alla volta, assicurandoti di delineare chiaramente questa attività dagli altri su cui le persone potrebbero lavorare e comunicare ai tuoi compagni di squadra che ci stai lavorando (redmine o altro tracciamento dei bug è ottimo per questo). Quindi, esegui le modifiche su base regolare e vengono trasferite al server di sviluppo / gestione temporanea, così come i tuoi compagni di squadra. Idealmente, hai dei test unitari integrati nel tuo sistema di integrazione continua (consiglio vivamente luntbuild o QuickBuild per questo, ma anche Hudson funziona). Il sistema o i test CI possono automaticamente rilevare eventuali conflitti che potresti aver introdotto non appena hai verificato il codice. Se è necessario apportare modifiche al contenuto (senza codice), farlo sul server di sviluppo / gestione temporanea.

Per quanto riguarda la parte del database, ho adottato sostanzialmente due scuole di pensiero qui (una terza scuola di pensiero, facendo differenze nel database, non discuterò perché la complessità è piuttosto elevata).

1) Distribuire rilasciando il database di produzione e importando un mysqldump del database di sviluppo. Facoltativamente, esegui in anticipo un regex trova / sostituisci su qualsiasi link assoluto codificato che faccia riferimento all'URL di sviluppo nel dump SQL. Dopo aver importato dev db in prod, esegui automaticamente le istruzioni SQL (di solito tramite script) in seguito per modificare eventuali impostazioni diverse per prod che dev (ad esempio, forse hai nella tabella delle variabili alcune impostazioni di connessione per la connessione a sistemi esterni che devi passare a puntare a sistemi esterni prod invece che alla versione dev).

2) Utilizzare il modulo Funzionalità, come indicato da budda, per le impostazioni dell'amministratore e utilizzare il modulo Esportazione nodo per l'esportazione / importazione del contenuto in combinazione con il modulo Elimina tutto. Quindi il flusso di lavoro è:

usa node_export e funzionalità per esportare nodi / funzionalità in file Opzionalmente (e si spera) controllo della versione Carica file sul sistema prod Usa usa drush o l'interfaccia di amministrazione per caricare funzionalità Usa drush delete-all o l'interfaccia di amministrazione per cancellare tutti i nodi dei tipi che vuoi importare Utilizzare drush ne-import o l'interfaccia di amministrazione per importare i nodi dal file dei nodi esportato. Una nota, suggerirei vivamente di adottare un flusso di lavoro standard, in cui il contenuto va solo in una direzione. Dev - Dev o Prod -> Dev (preferisco questo).

L'ho fatto e lo sto facendo su alcuni grandi sistemi, con risultati abbastanza buoni, ma ci saranno sempre molti modi per tagliare questa mela, scegli il modo in cui funziona meglio per te.

Mentre questa è una vecchia domanda con una risposta accettata, credo che ci sia ancora spazio per un'altra.

Innanzi tutto, lasciatemi dire in anticipo che non credo che Features sia lo strumento giusto per questo compito e che proporrà una serie alternativa di strumenti.

Un prerequisito per la collaborazione di gruppo è disporre di un server di gestione temporanea per testare le versioni di sviluppo del progetto separate dal server di produzione. Tutto il codice di deviazione viene testato sul server di gestione temporanea e inviato al server di produzione solo quando è stabile e pronto per la distribuzione. Tuttavia, gli sviluppatori non funzionano direttamente sul server di gestione temporanea. Ogni sviluppatore lavora nella propria postazione di lavoro, utilizzando un controllo di revisione e una gestione del codice sorgente (SCM) per coordinare il proprio lavoro con il resto del team.

Il sistema SCM consente ai membri del team di lavorare in parallelo su diversi rami del codice senza interferire tra loro. Solo il ramo principale viene distribuito sul server di gestione temporanea a scopo di test.

Per eseguire il mirroring del database tra produzione, gestione temporanea e workstation, esiste un modulo denominato Backup e migrazione che può essere utilizzato se si utilizza l'hosting condiviso e non si gestisce il proprio database. Se gestisci il tuo server di database, questo è l'unico progetto su quel server e usi mysql , sono utili le seguenti coppie di comandi:

Scaricare:

mysqldump --all-databases --opt -u root -p > DUMP.sql

Ripristinare:

mysql -u root -p < DUMP.sql

Se il tuo non è l'unico database su quel server, esegui lo script di una versione di mysqldump(o equivalente se non stai usando mysql ) che scarica solo i tuoi database.

Creare una politica che sia il database sul server di produzione a essere master. Il server di gestione temporanea e le workstation dovrebbero essere una copia del database di produzione, non viceversa.

Nota che Drupal 7 mantiene tutte le sue impostazioni di amministrazione nel database. Ciò significa che il mirroring del database tra il sito di produzione, il sito di gestione temporanea e le stazioni di lavoro eseguirà la migrazione delle impostazioni di admin senza funzionalità .

Ora, per condividere il codice:

Il modo standard per condividere il codice tra i membri di un team di sviluppo è utilizzare il sistema SCM. Drupal sembra essere gestito di default con un tale sistema chiamato git .

Git consente l'uso di repository locali o remoti. Se i membri del team si trovano nello stesso spazio fisico, è possibile impostare un repository locale sul server di gestione temporanea. Se sono distribuiti geograficamente, è possibile impostare un repository remoto. Se non ti dispiace che altri abbiano accesso in lettura al tuo codice in fase di sviluppo, puoi utilizzare un sandbox su Drupal.org come repository remoto. Puoi anche usare un'area di progetto su GitHub . GitHub non è solo un repository, ma include alcuni strumenti per la collaborazione e consente sia repository pubblici che privati.

Fondamentalmente, un sistema SCM consente ai membri del team di estrarre il codice sorgente e la documentazione dal repository condiviso dai membri del team e di reinserirlo dopo averci lavorato. L'SCM tiene traccia delle modifiche e in caso di conflitto (ovvero qualcuno cerca di spingere codice che non contenga le modifiche che un altro membro del team ha commesso), ti dirà e suggerirà anche un modo per risolvere questo conflitto.

Di solito, con qualche comunicazione cordiale su come i compiti sono divisi tra i membri del team, non ci saranno conflitti. Ma con il sistema SCM che tiene traccia delle cose, i conflitti diventano gestibili anche se vengono commessi errori o la comunicazione fallisce.

Esistono molti tutorial su come iniziare e usare git (GIYF). Due consiglierò: il sito web git-scm e Pro Git di Scott Chacon.