Devo controllare i moduli contribuiti nel mio progetto?


8

Mi è stato detto che durante lo sviluppo avrei dovuto controllare tutto sotto il sites/mio repository di codice (ad esempio SVN).

Supponendo che non toccherò mai nessuno dei moduli contrib che uso ( ctools, viewsecc.) Ma creerò solo il mio tema, dovrei ancora farlo?

O dovrei semplicemente controllare il codice sorgente di tutto sites/all/themes/?

Grazie

Risposte:


10

Nel mio team, ci siamo trasferiti a cercare solo ciò che è specifico per il nostro progetto attuale. Se stiamo usando Visualizzazioni, ad esempio, si aggiunge la voce appropriata al nostro Drush marca -file, e la versione che , ma non il modulo stesso.

Questo ci lascia con un repository molto piccolo, costituito da eventuali moduli personalizzati specifici per il sito corrente, il tema attuale e le esportazioni di funzionalità.

A meno che tu non riesca assolutamente a usare drush e drush make, non vedo perché si dovrebbe controllare il codice di versione che è ben versione altrove. E se hai intenzione di hackerare uno dei moduli, dovresti aggiungerlo di nuovo come sottomodulo , non eseguendo la versione del codice nel tuo repository. (Credo che questo sia chiamato filiale di un fornitore in SVN).

Modifica: per maggiori dettagli e una configurazione più avanzata, puoi dare un'occhiata a questo repository: git@github.com: letharion / Drupal-build-scripts.git Gli script sono scritti in bash per supportare il flusso di lavoro dei miei team che include un edificio un profilo di installazione di base ( NodeStream ), quindi il nostro profilo specifico del sito, un file di creazione per ciascun profilo, hook per applicare patch o apportare altre modifiche ai singoli passaggi di compilazione, ecc. Spero di trovare il tempo di ri -scriverlo come estensione di drush nel prossimo futuro.


Grazie per la tua spiegazione dettagliata. Sì, uso drush e piano per automatizzare il più possibile. E non ho intenzione di cambiare alcun codice nei moduli core o contrib.
Cherouvim,

La versione +1 del file make è un'ottima idea, penso che lo farò in futuro;)
Clive

1
@Letharion Non capisco bene come funzioni quando si sviluppa lo stesso sito con vari sviluppatori contemporaneamente? AFAIK drush effettua sempre il download di tutte le dipendenze e tenta di sovrascrivere i siti / i valori predefiniti, anche se quei moduli sono già stati D / L'd, o esiste qualche opzione non documentata per scaricare solo i moduli aggiornati / nuovi? In altre parole: capisco i vantaggi dell'utilizzo di Drush make per l'installazione di nuovo, ma come lo usi per mantenere sincronizzate le dipendenze dei moduli in un team distribuito?
Creynders

Uso questo approccio da oltre un anno, ma ora mi chiedo se sia davvero meglio che avere tutto in un repository quando si lavora con altri sviluppatori che potrebbero non ricostruire la piattaforma ogni giorno. Inoltre, questo approccio non è realmente compatibile con il modo in cui Acquia struttura i propri repository per il loro hosting cloud.
David Meister,

6

In contrapposizione alla risposta di @ Letharion, mettere tutto in SVN ha senso per alcune organizzazioni e dipende davvero da come si eseguono le implementazioni. Mettere moduli contributivi e temi in SVN può avere senso se hai mai bisogno di "tornare indietro nel tempo" e guardare una vecchia versione di un sito.

Un esempio di ciò è utile quando si sospetta un bug in un modulo contrib o si riscontra un comportamento diverso. Essere in grado di ripristinare una versione completa del passato può aiutare.

Ho anche trovato utile avere un'istantanea completa del sito in SVN quando ho bisogno di capire cosa ha fatto un client a un sito. Posso fare un'istantanea completa della loro versione e inserirla in SVN come ramo e confrontare.


Per tornare "indietro nel tempo" avrei anche bisogno del corrispondente backup completo del database. Perché alcune impostazioni e configurazioni si trovano nel DB. È giusto?
Cherouvim,

Sì. Il modulo Backup and Migrate e / o drush archive-backup è il tuo amico qui.
mpdonadio

1
L'uso di questo metodo consente di clonare un'intera installazione dal controllo della versione e da un backup, che può essere molto utile per lo sviluppo o il debug di siti live.
keithm,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.