(dis) vantaggi della messa in scena dev-> production usando 'drush rsync' vs 'git'?

9

Ho creato un sito Drupal sotto controllo git per il lavoro di sviluppo.

È genitore in un repository GIT master e nudo e, man mano che vengono apportate modifiche nei miei vari cloni git di lavoro di progetto, e rispedito al master, un hook post-aggiornamento invia immediatamente le modifiche a un singolo sito Web di staging live (http: / /staging.loc.). Niente di speciale, funziona come previsto.

Ho anche il drush-alias del sito "@STAGING". Occasionalmente, voglio promuovere le mie modifiche dal sito di gestione temporanea a un server di produzione.

Mi vengono in mente due metodi relativamente semplici:

(1) Nel momento in cui il sito di staging appare stabile, creare il sito di produzione come checkout git dal repository principale,

(2) utilizzare drush rsync+ drush sql-syncdal sito di gestione temporanea al sito di produzione.

Entrambi possono essere fatti funzionare. A parte il fatto che (2) sembra più Drupal-centrico / consapevole per natura - la droga è, dopo tutto, un insieme di strumenti specifici di Drupal - quali sono i meriti relativi dei due approcci?

C'è qualche motivo particolare che dovrei considerare (1) rispetto a (2)?

In entrambi i casi "Tutto" è sotto almeno un'istanza del controllo di revisione ...

drush version-control staging

— Clive
fonte

3

Ho usato entrambe le tecniche. Entrambi possono essere utilizzati per garantire che gli stessi file testati su @stage finiscano su @live. Il vantaggio di rsync è che non si finisce con file extra (es. ".Git" e associati) sul proprio server di produzione. Tendo a risincronizzarmi su un vps e uso git su una scatola che possiedo (ad es. Siti Intranet).

— greg_1_anderson
fonte

Grazie per il punto. Stavo solo guardando le opzioni di esclusione. Questo aiuta a mantenere le cose pulite. Iiuc, devo specificare con cosa escludere "rsync' => array ('exclude-paths' => '.git:.DS_Store:.gitignore:.gitmodules:',"nel file .rc, anche se non sono ancora sicuro di averne bisogno nelle specifiche dell'alias di origine e di destinazione o solo nell'una o nell'altra.

.git dovrebbe essere ignorato per impostazione predefinita. Esegui 'drush --simulate rsync [opzioni] @a @b' per vedere l'esatto comando rsync che Drush eseguirà. Usa --include-vcs se vuoi che drush rsync includa .git e altri file relativi a vcs.

— greg_1_anderson

Devo leggere più dettagliatamente; Non mi rendevo conto che .git era escluso. Grazie anche per il suggerimento di simulazione. Ri: l'OP, penso che continuerò con il 'drush rsync' in quanto è progettato per essere un metodo di distribuzione per drupal & works. git può funzionare ovviamente, ma ora ho trovato abbastanza commenti che non è progettato per la distribuzione ...

1

Il problema con l'utilizzo di drush rsync è che se ci sono più persone che spingono le modifiche al server.

Il tuo esempio mostra solo una persona che sta spingendo le modifiche.

Se hai lo sviluppatore A che spinge le sue modifiche e poi lo sviluppatore B che spinge le sue modifiche, vuoi che git risolva i conflitti o che lo sviluppatore B risolva i conflitti.

— Micheas Herman
fonte

1

In realtà io uso entrambi. svn / git e rsync hanno due scopi diversi. svn / git serve per il controllo del codice sorgente rsynce sql-syncper sincronizzare la stadiazione e la produzione in modo efficiente. drush rsync @staging @prodè molto difficile da battere in termini di semplicità ed è terribilmente facile da integrare in quasi tutti gli continuous Integrationambienti se si desidera immergersi ancora di più nella follia / metodologie della qualità del codice.

— stefgosselin
fonte

1

Personalmente uso Git per il controllo della versione, la distribuzione e la sincronizzazione di vari codebase di server e quindi rsync per spostare / sincronizzare i file degli utenti (ignorato aggiungendo determinati percorsi al file .gitignore).

— danbohea
fonte