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

13

Ho appena iniziato un nuovo lavoro lo scorso mese e sembra che non abbiano il controllo del codice sorgente per il loro codice. Si affidano ai backup che il loro provider di hosting esegue per loro.

Dopo aver parlato un po ', ho convinto il mio capo che avremmo sicuramente dovuto utilizzare il controllo del codice sorgente e dopo aver tenuto un breve seminario su di esso, l'intero team è a bordo; adoravano Mercurial.

Quindi in questo momento lavoriamo così:

º----------BitBucket
º---------/
º--------/

Io e gli altri tre sviluppatori hg pulldi BitBucket, apportiamo le nostre modifiche, quindi hg pusha BitBucket.

Ora per la distribuzione, qualcuno avrebbe bisogno di FTP i file più recenti verso il server di produzione.

Stavo pensando di installare Mercurial sul nostro server e di utilizzare hg clone(successivamente hg pull) per mantenere aggiornate le versioni in produzione.

º---push->-----BitBucket----<-pull-----º (production server)
º---push->----/
º---push->---/

E 'questa una buona idea? Eventuali potenziali insidie che potrei non vedere? Qualcuno qui ha fatto qualcosa di simile? Come si distribuisce un'applicazione framework PHP di grandi dimensioni (stiamo usando Moodle)?

php mercurial production

— sergserg
fonte

È un'idea fantastica. Perché hai dei dubbi?

— Nikolay Fominyh,

È un processo che molti fanno e considerano abbastanza "normale" che Microsoft ha ora il supporto integrato per eseguire le distribuzioni basate su Git (con il supporto di hg in futuro) nel loro servizio Azure.

— Alan Barber,

12

Questa è sicuramente una buona idea ed è un metodo comune da utilizzare per la distribuzione. È possibile che si desideri utilizzare un ramo stabile per scopi di distribuzione mantenendo il tronco per lo sviluppo continuo in modo da poter testare il ramo stabile prima di distribuirlo in produzione.

L'unico problema può sorgere quando nella tua base di codice sono presenti informazioni sensibili (come chiavi API ecc.) Che non desideri caricare su server di terze parti (nel tuo caso sarebbe Bitbucket). In questo caso, un semplice script che viene eseguito dopo aver estratto i dati dal repository per ripristinare i dati sensibili nella posizione corretta risolverà il problema.

— cromulent
fonte

10

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

Un modo per eseguire distribuzioni atomiche consiste nell'utilizzare collegamenti simbolici. Creare una directory contenente i nuovi file. quando tutto è pronto, cambia un link simbolico per la directory utilizzata. Se mantieni la vecchia versione in giro puoi anche facilmente tornare indietro.

— johannes
fonte

3

Puoi comunque eseguire facilmente il rollback, questo è il punto di VCS.

— Rob

1

non necessariamente - quindi è necessario mantenere la configurazione o alcuni file generati che potrebbero dipendere dalla versione e dal sistema nel VCS. Inoltre dovresti usare i tag (che non sono menzionati nel processo descritto nella domanda) per tornare a una versione funzionante conosciuta.

— johannes,

2

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

Breve spiegazione breve: questo è un server (può essere interno, non è necessario essere su Internet) che hai impostato per monitorare i tuoi repository e ogni volta che ci sono nuovi changeset nei repository, il server crea il tuo codice ( AFAIK questo non è necessario in PHP) , esegue test unitari e distribuisce il tuo codice sul web server.

Per ulteriori informazioni, controlla questi collegamenti:

Esistono molti prodotti diversi per CI , ma l'unico che ho usato finora è TeamCity . Molto facile da configurare ... in effetti, è il primo che ho provato e mi è piaciuto così tanto che ci sono rimasto.

Soluzione economica alternativa:

Se l'impostazione di un server di build è troppo impegnativa o se desideri un maggiore controllo su quando viene distribuito esattamente il tuo sito, imposta un file di script (Batch / Powershell su Windows o qualcosa di simile su Linux / Mac) che tira il versione più recente dal tuo repository e FTP sul server di produzione.

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

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

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

— Christian Specht
fonte

1

Facciamo questo, o cose simili a questo. L'angolazione non anatomica di @johannes è un problema, anche se in termini realistici accade così in fretta 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": distribuire in questo modo un codice errato semplifica la correzione. Il grosso problema è quando si distribuisce un aggiornamento che modifica il database che si desidera ripristinare. O se stai effettuando aggiornamenti errati e corrompendo i dati.

L'altro problema che abbiamo riscontrato con gli strumenti DCVS (rispetto all'utilizzo di SVN) è che ora hai una copia dell'intera base di codice sulla macchina in un punto in cui un attaccante potrebbe potenzialmente afferrare. E anche che quella base di codice DCVS può ottenere dimensioni piuttosto pesanti, il che potrebbe importare se stai pagando per l'archiviazione e / o il backup. Per questi motivi stiamo ancora utilizzando SVN per la distribuzione finale.

— Wyatt Barnett
fonte

1

È un'ottima idea, tuttavia tieni presente quanto segue:

Cerca di non impegnarti sul server (anche se alcune volte rare ha senso farlo, ad esempio installando un plugin o aggiungendo risorse di contenuto)
Utilizzare un server di gestione temporanea o una distribuzione di repository secondaria per i test
Fai sempre attenzione a hg update -Cnon influire sulla produzione (es. Elimina file importanti)
Avere una produzione e un ramo di sviluppo, distribuire solo il ramo di produzione
Tratta le risorse come backup (ad es. Immagini per il contenuto) e ignora i dati dell'utente (ad es. Allegati / caricamenti, cache, ecc.)
Avere sempre un hg statusoutput pulito sul server (questo ti aiuterà ad assicurarti di ignorare le cose come cache)
Non distribuire il repository nella cartella Web. Usa i collegamenti simbolici al di fuori dello spazio pubblico (ad esempio ln -s / myrepo / src / web / public_html / myapp)
Fare attenzione a non file di configurazione della versione (specialmente con password del database o altro)
Non utilizzare invece di un backup di produzione, si tratta di un backup di sviluppo per il codice di produzione , non per i dati di produzione

Infine, penso che la cosa più preziosa per aggiungere un DVCS al tuo processo di distribuzione sia che ciò aggiungerà sicurezza alla tua distribuzione, a volte gli hacker iniettano codice dannoso nelle tue cose e davvero non hai alcun modo di rilevarlo facilmente senza qualcosa come il controllo della versione ( appositamente distribuito, poiché l'aspetto distribuito a VCS semplifica il controllo dell'integrità dei file).

Alcuni siti sono stati hackerati alcune volte, avendo Mercurial mi aiuta a annullare letteralmente questi hack semplicemente emettendo un hg update -Cnel server (ovviamente potresti voler fare uno hg statuse ottenere i file interessati per successive analisi).

— dukeofgaming
fonte