È una buona idea installare Mercurial sul tuo server e hg pull per la distribuzione?

Questa è certamente una buona idea ed è un metodo comune da utilizzare per la distribuzione. Potresti voler utilizzare un ramo stabile ai fini della distribuzione, mantenendo allo stesso tempo il tronco per lo sviluppo in corso, in modo che tu possa testare il ramo stabile prima di metterlo in produzione.

L'unico problema può venire quando si hanno informazioni sensibili nella propria base di codice (come le chiavi API, ecc.) che non si desidera caricare su server di terze parti (nel caso specifico sarebbe Bitbucket). In questo caso, un semplice script che viene eseguito una volta estratti i dati dal repository per ripristinare i dati sensibili nella posizione corretta risolverà il problema.

Ricorda che questa strategia di implementazione non è atomica. Potrebbe accadere che alcuni file siano già aggiornati mentre altri file potrebbero essere ancora nel vecchio stato mentre l'applicazione viene colpita. Ciò può causare effetti collaterali imprevisti.

Un modo per fare distribuzioni atomiche è utilizzando i collegamenti simbolici. Crea una directory contenente i nuovi file. quando tutto è pronto cambia un link simbolico per la directory usata. Se mantieni la versione precedente puoi anche eseguire facilmente il rollback.

Un'altra possibilità (a mio parere migliore) : utilizzare un server di build / un server di integrazione continua.

Breve spiegazione breve: si tratta di un server (può essere in-house, non ha bisogno di essere su Internet) che si imposta per monitorare i repository e ogni volta che ci sono nuovi changeset nei repository, le build del server il tuo codice (AFAIK non è necessario in PHP) , esegue test unitari e distribuisce il tuo codice al server web.

Per ulteriori informazioni, controlla questi link:

• articolo di Wikipedia sull'IC
• Domanda Overflow dello stack: qual è il punto di un "Build Server" “?

Ci sono molti prodotti diversi per CI là fuori , ma l'unico che ho usato finora è TeamCity . Molto facile da configurare ... infatti, è il primo che ho provato, e mi è piaciuto così tanto che ne sono rimasto incollato.

Soluzione economica alternativa:

Se impostare un server di build è troppo impegnativo o se desideri un maggiore controllo su quando esattamente viene distribuito il tuo sito, imposta semplicemente un file di script (Batch / PowerShell su Windows, o qualcosa di simile su Linux / Mac) che estrae la versione più recente dal tuo repository e FTP sul server di produzione.

Fondamentalmente, è lo stesso di un build server, solo più semplice.

Non importa quanto esattamente lo risolvi alla fine ... assicurati di automatizzarlo in qualche modo!

Vuoi essere in grado di implementare con un solo clic / digitando un singolo comando, in modo che TUTTI possano farlo senza dover sapere nulla di speciale e senza commettere errori, anche in caso di disastro o sotto stress.

Facciamo questo, o cose simili a questo. Il non anatomico @johannes menziona l'angolo è un problema, anche se in termini realistici accade così velocemente che dovrebbe essere OK e ci sono modi per aggirare questo come sottolinea.

Probabilmente più importante di questa non-atomicità sarebbe "come si gestiscono gli aggiornamenti dello schema del database" - l'implementazione di codice errato in questo modo rende più semplice il fixing. Il grosso problema è quando si distribuisce un aggiornamento che cambia il database che si desidera ripristinare. O se si stanno facendo cattivi aggiornamenti e corrompendo i dati.

L'altro problema che abbiamo avuto con gli strumenti DCVS (al contrario di usare SVN) è che ora hai una copia dell'intero codebase sulla macchina in un posto che un utente malintenzionato potrebbe potenzialmente afferrare. E anche che la base di codici DCVS può diventare abbastanza pesante in termini di dimensioni, il che potrebbe essere importante se si sta pagando per l'archiviazione e / o il backup. Stiamo ancora utilizzando SVN per la distribuzione finale per questi motivi.

È una grande idea, tuttavia tieni presente quanto segue:

• Cerca di non eseguire il commit sul server (sebbene alcune rare volte abbia senso farlo, ad esempio installando un plug-in o aggiungendo risorse di contenuto)
• Utilizza un server di gestione temporanea o una distribuzione di repository secondaria per testare
• Fai sempre attenzione che hg update -C non influisca sulla produzione (ad esempio cancella file importanti)
• Avere un ramo di produzione e sviluppo, distribuire solo il ramo di produzione
• Tratta le risorse come backup (ad esempio immagini per il contenuto) e ignora i dati dell'utente (ad esempio allegati / caricamenti, cache, ecc.)
• Hai sempre un output hg status pulito sul server (questo ti aiuterà a essere sicuro di ignorare le cose come cache)
• Non distribuire il repository nella cartella web. Utilizza i link simbolici dall'esterno dello spazio pubblico (ad es. Ln -s / myrepo / src / web / public_html / myapp)
• Attenzione ai file di configurazione delle versioni (specialmente con password del database o altro)
• Non utilizzare al posto di un backup di produzione, questo è un backup di sviluppo per il codice di produzione, non per i dati di produzione

Infine, la cosa più preziosa per aggiungere un DVCS al processo di distribuzione è che questo aggiungerà sicurezza alla tua implementazione, a volte gli hacker inseriscono codice dannoso per la tua roba e non hai davvero alcun modo di rilevarlo facilmente senza qualcosa di simile controllo di versione (appositamente distribuito, dal momento che l'aspetto distribuito a VCS rende più facile verificare l'integrità dei file).

Alcuni siti sono stati violati un paio di volte, dopo che Mercurial mi ha aiutato litterally a annullare questo hack solo emettendo un hg update -C nel server (ovviamente potresti voler fare un hg status e recupera i file interessati per un'analisi successiva).