it-swarm.it

Puoi suggerire modi per gestire la distribuzione del codice su un server Web basato su Linux?

Ho sempre usato uno script bash molto semplice per distribuire il codice. Mi sto allontanando dall'utilizzo di Subversion a Mercurial ma non credo davvero che il software di controllo delle revisioni sia importante per la distribuzione.

Quali sono alcuni modi migliori per farlo?

#!/bin/sh
date=`date +%Y%m%d_%H%M%S`
tar -zcvf app-dir-$date.tar.gz app/dir 
tar -zcvf app-templates-$date.tar.gz app/templates
tar -zcvf app-media-$date.tar.gz app/media
svn export http://example.com/somepath/trunk hh/ --force
7
citadelgrad

Uso Mercurial per gestire tutto , comprese le mie pagine HTML statiche. Rende la vita davvero molto facile per me.

I vantaggi includono

  • Tutte le offerte di controllo versione vantaggi (rollback, tag milestone, ecc.)
  • Essere in grado di clonare il tuo sito in fretta
  • Hai sempre un backup/copia locale funzionante
  • Facile da mantenere sincronizzato se si tende ad apportare modifiche in loco (sul posto, sul server)
  • La maggior parte degli host condivisi (se ne hai a che fare con uno) non dispiace installarlo

Disclaimer, ho scritto il tutorial. Sì, il tipo di VCS che usi è importante fino a un certo punto. Ad esempio, non userei qualcosa in questo scenario in cui non potrei impegnarmi localmente e fare un grande push/aggiornamento. Ciò mi obbliga a raggruppare troppi cambiamenti potenzialmente problematici in un unico impegno.

I potrei farlo con Subversion e non sto affatto bussando a SVN. Penso solo che Mercurial sia uno strumento molto migliore per il problema che stai cercando di risolvere.

È mia opinione che non dovresti dover "aggirare" i tuoi strumenti a meno che tu non abbia altra scelta. In questo modo sconfiggi lo scopo di averli, e tu hai una scelta :)

5
Tim Post

Oltre agli eccellenti suggerimenti nelle altre risposte, potresti voler considerare se per te è importante fare un aggiornamento atomico.

Sul mio server FreeBSD, realizzo questo attraverso due meccanismi:

  • Controllo delle versioni di tutte le mie risorse statiche. (Es. http://static.example.com/images/logo.1.png o http://static.example.com/style/main.3.css). Questo mi permette di svn update il sito statico direttamente prima di aggiornare il sito dinamico, senza preoccuparmi che gli utenti vedano nuovi file nelle vecchie pagine.

  • Controllo delle versioni dell'intero sito Web dinamico. Nel mio caso, ho la radice del mio documento che punta a un collegamento simbolico. La mia strategia è quella di mettere in atto la nuova versione della produzione e poi con un solo comando Push it live. .es. qualcosa come questo:

    cp -Rp www.site1.com.1 www.site1.com.2 (o svn checkout)

    svn update site1.com.2 (potrebbe essere necessario prima un svn switch)

    ln -sf site1.com.2 www.site1.com (sposta atomicamente le modifiche alla produzione)

Questo assicura che nessuno dei miei utenti finisca per vedere una pagina a metà. Vedranno la vecchia versione se è ancora nella loro cache o quella nuova.

Questa strategia funziona bene solo se non stai mescolando contenuti caricati dall'utente con il tuo sito dinamico.

1
JasonBirch

Usiamo ant's task scp , con selettore modificato . Ciò significa che devi semplicemente aggiornare i file che sono stati modificati rispetto al caricamento precedente. Sfortunatamente, il selettore modificato sembra essere progettato solo per uso personale, non condividendolo con i membri del team. Il file cache.properties ha nomi di percorso per la directory di lavoro dell'utente al suo interno. Abbiamo scritto un sacco di target di formiche per massaggiare il file cache.properties in un formato che può essere condiviso tra gli sviluppatori e poi massaggiato nel formato di cui ha bisogno la formica. Il formato varia anche tra un ambiente Windows e un ambiente GNU/Linux.

0
Don Kirkby

Non è il punto di usare il controllo versione che non devi preoccuparti di eseguire il backup del sito prima di inviare un aggiornamento?

Se è fatto correttamente, un svn update (o equivalente) dovrebbe essere sufficiente e se si tratta di un errore, ripristinalo a un commit precedente? Questo è quello che facciamo comunque. Conferma tutte le modifiche, svn update il server di gestione temporanea, se è tutto a posto quindi svn update il server live.

0
Mark Henderson